Printable View
I was just reading the marvellous piece on the subject "The C Programming Language" By "Kernighan and Ritchie",it suggested one thing:
While reading a file character by character,using getchar( ),we must use a large data type(like int) to check for EOF,not char.But here my program(taking char) works fine:
char c;
while((c=getchar( ))!=EOF)
putchar(c);
Can someone please help in clearing the confusion?
This link may be of some help.
Jim
Rachit, you either got lucky (in a bad way) or you haven't actually tested your code well enough (with input that causes getchar() to return EOF). EOF is usually a value that a char type cannot represent, so your while loop will never end.
EOF is -1; When youa ssign it to a char, you get 0xFF and the leading bits are trucated.
Most text files won't contain character 255 (&ymul; , a smal Latin y with a twiddly bit on top). So the code is fine, until you happen to open such a file.
The above assumes char is signed; if unsigned the issue differs in that the EOF can not be detected as posted in prior post.Quote:
Originally Posted by Malcolm McLean
Also, EOF is normally -1 NOT always -1.
Tim S.
The code posted will compile and run, but if you really are reading in a file, it won't finish running. As you already know, the char data type is not large enough in most cases to hold the EOF value defined.
Not really. If char is unsigned, then the value of EOF would be converted to be within the range of char, so the "won't finish running" thing wouldn't happen, but the code would be incorrect. If char is signed, then it depends on what is the value of EOF, but as was mentioned earlier, EOF is often defined as -1, which would fit into a signed char, though the code would still be incorrect.Quote:
Originally Posted by jwroblewski44
On my system, if you assign EOF to an unsigned char, it becomes 255. 255 seems to a "non-breaking space" in the extended ascii. Disclaimer: I may be wrong.... :pQuote:
If char is unsigned, then the value of EOF would be converted to be within the range of char[...]
I guess what I'm trying to say is I see no reason not to use the type integer to deal with file I/O and EOF.
Oh, you are right: the promotion of char to int would yield the converted value, which would then be compared to the original value of EOF, hence there would be no value of c that would compare equal to EOF, if char is unsigned.
That is how unsigned types work - modulo arithmetic. Similarly, subtract 1 from zero, and the result is the maximum value that the type can represent (255 in the case of a typical 8-bit unsigned char).Quote:
Originally Posted by jwroblewski44