Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site mplvax.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!decvax!ittvax!dcdwest!sdcsvax!sdcc3!mplvax!cdl
From: cdl@mplvax.UUCP (Carl Lowenstein)
Newsgroups: net.lang.c
Subject: Re:  ugliness in scanf(3)
Message-ID: <190@mplvax.UUCP>
Date: Thu, 9-May-85 16:00:27 EDT
Article-I.D.: mplvax.190
Posted: Thu May  9 16:00:27 1985
Date-Received: Sun, 12-May-85 05:38:38 EDT
References: <10496@brl-tgr.ARPA>
Reply-To: cdl@mplvax.UUCP (Carl Lowenstein)
Organization: Marine Physical Laborator of SIO at UCSD
Lines: 18
Summary: 

In article <10496@brl-tgr.ARPA> gwyn@Brl.ARPA (VLD/VMB) writes:
>That's not a bug, it's a feature.  How else would you be able
>to determine what comes next when a scanf stops prematurely?
>If it ate the "failing" character, you could never see what it
>was.  I think the routine was designed on the assumption that
>the programmer would not be so stupid as to keep trying to
>scan a chunk of input over & over with the same failing format.

*mild flame*

This programmer is so stupid as to expect to find the behavior
of scanf documented in the manual.

*unflame*

-- 
	carl lowenstein		marine physical lab	u.c. san diego
	{ihnp4|decvax|akgua|dcdwest|ucbvax}	!sdcsvax!mplvax!cdl