NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/unix/aix/11723

Text File | 1992-11-19 | 1.9 KB | 50 lines

Newsgroups: comp.unix.aix
Path: sparky!uunet!spillman!tye
From: [e-mail] (E. Tye McQueen)
Subject: Re: Simple EOF problem?
Message-ID: <[e-mail]>
Date: Thu, 19 Nov 1992 15:06:44 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Spillman Data Systems
Lines: 39

[e-mail] (Dan Watts) writes:
)|In article <BxvzEE.79B@>, [e-mail] (vidyaranya) writes:
)||> The following piece of code FAILS to detect End of File
)||> under AIX(i dont know the version currently!) running on
)||> an IBM PowerServer 970.
)||> ------
)||>    char    buffer[2048];
)||>    int i;
)||>    FILE    *fp;
)||>
)||>    i=0;
)||>         while( (buffer[i++]=fgetc(fp))!= EOF )
)||>          ;
)||> ------
)||> Exactly same piece of code runs on a SparcStationIPC running
)||> SunOS 4.1.2 .
)||>
)||> What could be the problem?
)As mentioned above, fgetc returns int and EOF is -1.  On AIX, chars
)are *not* signed.  So, the -1 gets truncated to 0xFF to fit into
)buffer[].  The 255 is then compared to -1 and sure enough, they're
)not equal.

And that code will break on a SparcStationIPC running SunOS 4.1.2
since reading in a character 0xff will cause fgetc(fp) to return 255
which will get shoved into buffer[i++] and become -1 so the code
will detect EOF when there isn't one.

You can't encode end-of-file (of characters) with a character value
unless you do something like old MS-DOS where they have "files of
characters-other-than-CTRL-Z".  But that was never a good idea.

The code will also happilly overfill buffer[] for even moderately
large files.  You might try fread() instead (and its faster).

 [e-mail]                         Tye McQueen, E.
----------------------------------------------------------
 Nothing is obvious unless you are overlooking something.
----------------------------------------------------------