ugliness in scanf(3)

[Geoff Collyer]

In article <10600 at brl-tgr.ARPA> gwyn at brl-tgr.ARPA (Doug Gwyn) writes:
>> ... I can *answer* questions from users too *lazy* to *read*
>> the manuals...
>
>UNIX was developed by and for intelligent programmers.

printf(3S) and scanf(3S) are incomplete and slippery specifications.
If you doubt this, try writing the code from the manual pages.  The
current manual pages (and source code?) seem to be descended from the
v6 Portable C library (-lp) and have never been substantially
modified.

The v7 printf(3S) implies that one can supply a format specifier of %lu
to print an unsigned long int.  The v7 C compiler doesn't support
unsigned longs, yet %lu will print a long int as if it were unsigned.
It is possible to express this in C (assuming twos-complement
representation) by heroic measures.

What should printf do when given the format specifier %017s and a
string shorter than 17 characters?  I read printf(3S) as saying that
printf will pad with zeroes, though the v7 printf (at least) pads with
blanks and Dennis Ritchie has argued that this is desirable behaviour.

Various of System III or V don't support zero padding when the field
width begins with a zero.  AT&T has converted this incompatible
behaviour from a bug into a feature by documenting it (at least in
System V).  To date, ANSI has wisely sided against AT&T in this case.

scanf(3S) implies that inappropriate characters in the input will be
left unread, but this is not possible, given stdio's (zero or) one
character of pushback, for pathological input such as 3.4e-z under %f;
the best one can do is to push back the z, though all of e-z should be
pushed-back.

At a quick glance, the draft ANSI C library write-ups for printf and
scanf seem better than the UNIX manual pages, though still not as
explicit as I would like.
-- 
"All I'm after is just a *mediocre* brain,
 something like the president of the AT&T Company." - Alan Turing