Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!caen!uflorida!haven!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: What's so bad about scanf anyway???
Message-ID: <14561@smoke.brl.mil>
Date: 23 Nov 90 17:37:17 GMT
References: <1990Nov20.123036.11103@ericsson.se> <3797@skye.ed.ac.uk> <1990Nov22.071319.3222@ericsson.se>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 50

In article <1990Nov22.071319.3222@ericsson.se> epames@eos.ericsson.se writes:
>^D is *NOT* an eof character, it is a command to the tty driver to send
>the contents of the input buffer, ...

The character that in "cooked" mode is interpreted by the terminal driver to
act as an invisible line delimiter is normally called the EOF character in
UNIX user documentation.  While most people map ^D to this control function,
the choice is programmable.

In any event, the (cooked mode) input sequence
	A B <EOF> C D <NL> E F <EOF> <EOF> G H <NL> <EOF> I J
(where <EOF> is often ^D and <NL> is often ^M)
results in four "packets" being inserted into the terminal input queue:
	A B
	C D \n
	E F
	<empty>
	G H \n
	<empty>
with the two characters I and J still buffered for canonical (erase/kill)
processing.
The first subsequent read() on the terminal (assuming that several characters
are requested for the read count) will return the two characters:
	A B
The second such read() will return the three characters:
	C D \n
the third such read() will return:
	E F
The fourth read() will return:
	<empty>
The fifth read() will return:
	G H \n
The sixth read() will return:
	<empty>
(That is the only use for the EOF character that most UNIX users are
aware of.)
The seventh read() will block until a line delimiter is input.

The standard I/O functions need to be prepared to deal with this behavior,
generally by having input operations loop until enough data is obtained to
satisfy the implementation request (i.e. up to a \n for gets() or until the
requested count is satisfied for fread()).  While doing this, a read() that
returns 0 characters is conventionally interpreted as an "end of file"
indication.  While most applications will not read past an EOF indication,
on stream-like input channels such as terminals this might be a reasonable
thing to do under some circumstances.

Anyway, this is the intended UNIX behavior.  There are undoubtedly
variations even among UNIX implementations, and other operating systems
may have significantly different terminal input support.