What's so bad about scanf anyway??? (really what's bad about gets)

Richard A. O'Keefe ok at goanna.cs.rmit.oz.au
Thu Nov 22 15:55:32 AEST 1990


In article <1990Nov20.123036.11103 at ericsson.se>, epames at eos.ericsson.se (Michael Salmon) writes:
: In article <4319 at 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.

It would have been better to try understanding it first.
I wrote
	Let <EOF> represent your end-of-file character on a UNIX system.
People who have a UNIX system and don't know what I'm talking about should
read the "stty" manual page.  If they still don't understand, they should
find someone who does understand and get an explanation.  That or refrain
from posting.  The point is, of course, that the way you signal end-of-file
from a keyboard in UNIX is by typing a particular character.   Q: _Which_
character?  A: _You_ get to pick.  Some people use End-of-Transmission (^D).
Some people like ^Z.  I've seen ^Y used.

: In C EOF is not a character, its
: value is such that it can *NEVER* be present in a file.

So flipping what?  I said nothing whatsoever about C's EOF macro.
I was talking about the key you type at the keyboard.  This is totally
independent of C's EOF macro and the two values have nothing in common.
What I was doing was exhibiting a method of tricking gets() into reading
an arbitrary number of characters from the keyboard as one "line"; that
method relies on the malicious typist typing his <EOF> character from time
to time, whichever character he has selected for that purpose.

-- 
I am not now and never have been a member of Mensa.		-- Ariadne.



More information about the Comp.lang.c mailing list