Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!olivea!mintaka!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: <1990Nov20.123036.11103@ericsson.se>
Date: 20 Nov 90 12:30:36 GMT
References: <VXogs2w163w@cybrspc> <1990Nov16.165203.18786@zoo.toronto.edu> <4319@goanna.cs.rmit.oz.au>
Sender: news@ericsson.se
Reply-To: epames@eos.ericsson.se
Organization: Ericsson Telecom AB
Lines: 18

In article <4319@goanna.cs.rmit.oz.au> Richard A. O'Keefe writes:
>gets() will keep on reading from stdin until it hits a \n or an EOF.
>Lines entered from a keyboard _normally_ end with a \n, but they don't
>have to.  Let <EOF> represent your end-of-file character on a UNIX system

This is getting a long way from the original point but I thought I
should respond to this statement. In C EOF is not a character, its
value is such that it can *NEVER* be present in a file. In all the C
implementations that I have ever seen EOF has been represented by the
value -1 but it can be any integer and one of the traps that I think
everyone falls for at some time is to presume that getc() returns a
character rather than an integer.  EOF is never 255 or ^D, it is in
fact a read() that returns 0 as the byte count. N.B. the least
significant char of the usual representation of -1 is 255.

Michael Salmon
L.M.Ericsson
Stockholm