don@umd5 (Chris Sylvain) (10/21/86)
[]
Why "while( fputc(fgetc(fd), fe) != EOF )" quit working as it
did under both 2.9BSD and Ultrix 1.2 ...
1) At the end of file, fgetc() returns (int) -1.
2) fputc() prints (char) -1 and then returns a CHAR not an INT.
Naturally, (int) -1 != (char) -1, so we have a problem.
Question is now: can I deduce that under 2.9BSD and Ultrix
in the above code fragment there is an implied cast, i.e.,
(char) EOF or (int) fputc() ?
[thanks to everyone who responded to the previous posting.]
--
--==---==---==--
.. O frabjous day! Callooh! Callay! ..
ARPA: don@umd5.UMD.EDU BITNET: don%umd5@umd2
UUCP: ..!{ seismo!umcp-cs, ihnp4!rlgvax }!cvl!umd5!don
** WARNING: don@mimsy.UMD.EDU is a different person **
** (umcp-cs and mimsy.umd.edu are the same machine) **
** --> Please double-check the address <-- **chris@umcp-cs.UUCP (Chris Torek) (10/22/86)
In article <1322@umd5> don@umd5 (Chris Sylvain) writes: >Why "while( fputc(fgetc(fd), fe) != EOF )" quit working as it >did under both 2.9BSD and Ultrix 1.2 ... Chances are it never really worked: fputc(EOF, fe) is likely to put a meta-DEL into file `fe'. >1) At the end of file, fgetc() returns (int) -1. >2) fputc() prints (char) -1 and then returns a CHAR not an INT. Actually, fputc returns (unsigned char)c, which turned EOF to 255. >Naturally, (int) -1 != (char) -1, so we have a problem. On Ultrix 1.2 Vaxen and 2.9BSD 11s, (int) -1 *is* equal to (char) -1. The code is wrong in the first place; fputc is not supposed to be handed an EOF. What it does in such cases is undefined. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu