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