[net.unix] mixing scanf and gets

gwyn@brl-smoke.UUCP (04/03/86)

In article <1740@ittatc.ATC.ITT.UUCP> yoda@ittatc.ATC.ITT.UUCP (Todd C. Williams [Jedi Knight]) writes:
>Is it possible to use gets() after scanf() ?
>Is it a good idea to try to use gets() after scanf() ?
>It doesn't work, so I tried adding "fflush(stdin);" 
>just before the gets(), but that doesn't help either.
>If I do 2 "gets(str)"'s in a row, the second one works.
>
>Apparently, the scanf() is reading UP TO the newline, but
>leaving that newline in the buffer; the gets() sees the
>newline and thinks it is finished.

scanf() does whatever you tell it to with the input stream
then stops.  If you make it eat newlines, it will.  There
should be no problem mixing any of the STDIO input methods.

However, it sounds to me like your application would be
programmed better with the following scheme:

	while get-a-line-using-fgets
		parse-line-with-sscanf

By the way, don't use gets(); your input buffer can be
overrun if an input line is very long, resulting in
unpredictable malfunctioning of your application.  When
you use fgets(), it is often wise to test the last
character in the record and if it is a newline, replace
it with a 0 string terminator before parsing the record.

Since this advice is independent of UNIX, I'm cross-posting
to net.lang.c.

guy@sun.uucp (Guy Harris) (04/06/86)

> However, it sounds to me like your application would be
> programmed better with the following scheme:
> 
> 	while get-a-line-using-fgets
> 		parse-line-with-sscanf

From my experience, just about *any* application would be programmed better
using "fgets" and "sscanf" instead of "scanf"....

> By the way, don't use gets(); your input buffer can be
> overrun if an input line is very long, resulting in
> unpredictable malfunctioning of your application.  When
> you use fgets(), it is often wise to test the last
> character in the record and if it is a newline, replace
> it with a 0 string terminator before parsing the record.

And if it is NOT a newline, yell, scream, and bitch that somebody gave you a
line which was too long; otherwise, your program will think that the rest of
the line (i.e., everything after the cutoff) is an additional line.  The
SCCS "delta" command, when reading the output from "bdiff", didn't do this,
and got HORRIBLY confused if the new version of the file had a line longer
than about 510 characters long.
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.arpa	(yes, really)