Correct use of scanf

Marty fouts at ames-nas.ARPA
Thu Mar 7 14:43:59 AEST 1985


The following simple program:

	#include <stdio.h>
	main()
	{
		char buf[255];
		int r;
		setbuf(stdin,NULL);
		setbuf(stdout,NULL);

		while ((r = scanf("%[^\n]\n",buf)) != EOF) {
			printf("scanf returned %d",r);
			printf(" and the string %s\n",buf);
		}
	}

has an interesting behavior problem.

     The key to the program is the scanf, which (if I read the
description of scanf in the manual correctly) should return an entire
line of input from stdin into buf each time it is called, except that
once (at the end of file input) it should return EOF, causing the while
loop to exit.

     On all of the systems I tested, this is the way it behaved when
STDIN was redirected to be from a file.  When STDIN is the tty, an
interesting problem occured.  On ALL systems tested, the second line of
input had to be read before the first line was output.  For instance, a
session might look like:

(I type)	a
(I type)        b
(It replies)	scanf returned 1 and the string a
(I type)	c
(It replies)	scanf returned 1 and the string b

     etc.  A further complication occurs when I try to exit the program
by typing an EOF character.  BSD 4.2 systems behave as I thought they
would and exit immediately after the first EOF, as do VMS (3.7)
systems.  AT&T System V Release 2, as well as a derivitive from Silicon
Graphics required that I type EOF twice.

     I assume that the first bit of behavior is related to a problem
similar to the one exhibited by PASCAL, which has to be an entire line
ahead before it can determine that a line of input has been read,
unless "lazy" keyboard i/o or something similar is implemented.

     The second problem seems to be a bug in the semantic
interpretation of EOF on the part of SV and its clones.  Both problems
seem to me to be unnecessary deviation from the idea of device
independent i/o, as defined in Unix.

     Additionally, three of the four implementations tested stripped
leading spaces from the input.  (The string "  a", with two spaces
before the a, is returned as "a", in buf.)  Only 4.2 returned the
leading space, which is the way the manual appears to claim it should
be done.

     What is the "correct" behavior (best behavior?) for the first two
problems?  Which way is the correct interpretation for leading spaces?

     Please reply to me directly, and I will attempt to summarize for
the net, if there is sufficent interest.

Marty Fouts
fouts at ames-nas
ames!amelia!fouts

----------



More information about the Comp.unix.wizards mailing list