Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site umd5.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!umcp-cs!cvl!umd5!zben
From: zben@umd5.UUCP
Newsgroups: net.lang.c
Subject: Re:  ugliness in scanf(3)
Message-ID: <512@umd5.UUCP>
Date: Tue, 14-May-85 23:12:15 EDT
Article-I.D.: umd5.512
Posted: Tue May 14 23:12:15 1985
Date-Received: Thu, 16-May-85 20:29:41 EDT
References: <10496@brl-tgr.ARPA> <190@mplvax.UUCP> <189@mplvax.UUCP> <714@oddjob.UUCP>
Reply-To: zben@umd5.UUCP (Ben Cranston)
Organization: U of Md, CSC, College Park, Md
Lines: 81
Summary: Flame down, *REAL DOCUMENTATION*

In article <714@oddjob.UUCP> matt@oddjob.UUCP (Matt Crawford) writes:
>In article <190@mplvax.UUCP> cdl@mplvax.UUCP (Carl Lowenstein) writes:
>>In article <10496@brl-tgr.ARPA> gwyn@Brl.ARPA (VLD/VMB) writes:
>>>
>>>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.
>>
>>This programmer is so stupid as to expect to find the behavior
>>of scanf documented in the manual.
>>
>THIS programmer is not too arrogant to open the manual before telling
>someone what's not in it:
>
>SCANF(3S)	    UNIX Programmer's Manual		SCANF(3S)
>
>     For example, .....
>
>	  int i; float x; char name[50];
>	  scanf("%2d%f%*d%[1234567890]", &i, &x, name);
>
>     with input
>
>	  56789	0123 56a72
>
>     will assign 56 to i, 789.0	to x, skip `0123', and place the
>     string `56\0' in name.  The next call to getchar will return
>     `a'.                    ------------------------------------
>     ----
>

The same documentation appears on our 2.9BSD system - I guess it is the same
on 4.xBSD - and yes, a reasonable person should be able, after scratching his
head for awhile, figure out what is happening.

How much time do you waste scratching your head?

The following mail arrived and I think it germane:

-------------------------------------------------------------

I get tired of people saying that UNIX & C are not documented.  There are
a few undocumented features of programs, but they are that way because they
might go away, and shouldn't be used (yet).  E.g., the VPATH variable in
make.  But all the system functions are documented *quite well*.  Take
the scanf manual page:

----
Scanf conversion terminates at EOF, at the end of the control string, or when
an input character conflicts with the control string.  In the latter case, the
offending character is left unread in the input stream.

Scanf returns the number of successfully matched and assigned input items;
this number can be zero in the event of an early conflict between an input
character and the control string.  If the input ends before the first conflict
or conversion, EOF is returned.
----

If that isn't *painfully obvious*, I don't know what is.  Maybe you're using
4.2BSD; if you do, I apologize.  That system is a total hack munged by grad
students and the documentation is even worse.  This excerpt comes from SVR2.
Since it is a production system, it has to be well-documented, and it is.

						Michael Baldwin
						AT&T Bell Labs

-------------------------------------------------------------

Now *this* is adequate documentation...

Re: "high priest" thing.  It's very easy to tell the most vicious form of
Polack joke, until you really become friends with a Pole.  It must similarly
be very easy to eliminate upon "high priests", until you are confronted with
one.  Maturity consists in large measure of doing what is right in preference
to doing what is easy.

Nuf said?

-- 
Ben Cranston  ...{seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben  zben@umd2.ARPA