Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!ericom!eos.ericsson.se!epames
From: epames@eos.ericsson.se (Michael Salmon)
Newsgroups: comp.lang.c
Subject: Re: What's so bad about scanf anyway??? (really what's bad about gets)
Message-ID: <1990Nov23.092342.4355@ericsson.se>
Date: 23 Nov 90 09:23:42 GMT
References: <1990Nov20.123036.11103@ericsson.se> <1990Nov22.071319.3222@ericsson.se> <4354@goanna.cs.rmit.oz.au>
Sender: news@ericsson.se
Reply-To: epames@eos.ericsson.se
Organization: Ericsson Telecom AB
Lines: 30

In article <4354@goanna.cs.rmit.oz.au> Richard A. O'Keefe writes:
>I wrote
> Let <EOF> represent your end-of-file character on a UNIX system
>
....
>
>The SVID release 2 has the same text, and speaks of
>	The ERASE, KILL, and EOF characters ...
>
>So when I wrote of an "end-of-file character" I was using *precisely*
>the terminology blessed by the SVID, which nowhere calls it a "command".

I agree that that is what the manual says and I think it is unfortunate
as it doesn't mean end of file as defined by gets() etc. I quote below from
SunOS man page for termio.

     EOF       (CTRL-D or ASCII EOT) may be used to  generate  an
               end-of-file  from  a terminal.  When received, all
               the characters waiting to be read are  immediately
               passed  to the program, without waiting for a NEW-
               LINE, and the EOF is discarded.   Thus,  if  there
	       are no characters waiting, which is to say the EOF
               occurred at the beginning of a line, zero  charac-
               ters  will  be  passed back, which is the standard
               end-of-file indication.

Strictly my own opinions.
    Michael Salmon
    L.M.Ericsson
    Stockholm