Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!bloom-beacon!bu-cs!buengc!bph
From: bph@buengc.BU.EDU (Blair P. Houghton)
Newsgroups: comp.lang.c
Subject: In defense of scanf() (Re: Re^2: scanf(..))
Message-ID: <3145@buengc.BU.EDU>
Date: 14 Jun 89 17:15:42 GMT
References: <225800176@uxe.cso.uiuc.edu> <11831@bloom-beacon.MIT.EDU> <4734@freja.diku.dk> <4529@ficc.uu.net>
Reply-To: bph@buengc.bu.edu (Blair P. Houghton)
Followup-To: comp.lang.c
Organization: Boston Univ. Col. of Eng.
Lines: 32

In article <4529@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
>scs@adam.pika.mit.edu (Steve Summit) writes:
>>It is only a miserable problem when scanf
>>is being used for interactive user input, which is what everybody
>>uses it for.

"Eeep", and "yoicks!"

>Anyone using scanf directly for interactive input... or for any input at
>all... should have their head examined.
>
>The only really safe way to use scanf() without freaking out the casual
>user of your code is to do something like this:
>
>	fgets(buffer, sizeof buffer, stdin);
>	sscanf(buffer, fmt, args...);

I'll go along with the "don't use it for interactive input" idea, but
not the "for any input at all"...

When filtering tabular data from files, or dealing in a situation where
a precise syntax is necessary, the `fgets(..); sscanf(..)' doublet just
adds uncertainty and complexity to a simple problem to which scanf is
suited ideally.  If there is an error reading something in that case,
you usually force a barf.  It's irrelevant whether the input gets
discarded.

The point is, don't reject scanf() just because it's unsuited to a problem
you aren't solving.

				--Blair
				  "We pay csh for used car's..."