What's so bad about scanf anyway??? (really what's bad about gets)
Richard Tobin
richard at aiai.ed.ac.uk
Thu Nov 22 02:46:01 AEST 1990
In article <1990Nov20.123036.11103 at ericsson.se> epames at eos.ericsson.se writes:
>should respond to this statement. In C EOF is not a character, its
You seem to have misunderstood Richard O'Keefe's point. By EOF,
Richard meant the C #defined constant, normally -1. By <EOF>, he
meant the key you press to send end-of-file (perhaps ^D), which is why
he said:
>>Let <EOF> represent your end-of-file character on a UNIX system
When you type <EOF> after a <linefeed> (or another <EOF>) it results
in read() returning zero, and getc() returning EOF. This is the
"normal" use of the <EOF> key.
When you type <EOF> at other times (eg after typing some letters), it
causes the line to be made available for read()ing, just as <linefeed>
does. However, there is no \n character (or ^D or whatever) appended
to the data. Typing
abc<EOF>
results in read() returning 3 and getting the characters 'a', 'b', and
'c'. Thus you can type in something that's a line from the point of
view of the tty driver, but doesn't end with '\n' and isn't a line
from the point of view of fgets(), which does something like
while(--count > 0 && (c = getc(file)) != EOF && c != '\n')
completely ignoring the boundaries of data returned by read().
-- Richard
--
Richard Tobin, JANET: R.Tobin at uk.ac.ed
AI Applications Institute, ARPA: R.Tobin%uk.ac.ed at nsfnet-relay.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin
More information about the Comp.lang.c
mailing list