Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!sun!guy
From: guy@sun.uucp (Guy Harris)
Newsgroups: net.unix,net.lang.c
Subject: Re: mixing scanf and gets
Message-ID: <3454@sun.uucp>
Date: Sun, 6-Apr-86 16:44:35 EST
Article-I.D.: sun.3454
Posted: Sun Apr  6 16:44:35 1986
Date-Received: Wed, 9-Apr-86 22:10:52 EST
References: <1740@ittatc.ATC.ITT.UUCP> <2336@brl-smoke.ARPA>
Distribution: net
Organization: Sun Microsystems, Inc.
Lines: 26
Xref: watmath net.unix:7571 net.lang.c:8444

> 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)