RE: printf field width argument handling

["Howland Craig D (Craig)" <howland at LGSInnovations dot com>]

A minor point:  fixed format strings are not necessarily used in such a
way that they can be checked at compile time.  For example:

int ucase=1;	// Flag for printing hex numbers with uppercase
const char *const fmt[] = { "Pointer %x\n", "Pointer %X\n" };
...
printf(fmt[ucase != 0], &var);
 
That noted, it would seem to be enough of an outlier that by itself it
would not warrant a change.  This part of the email is mostly to get
this into the record to show that we considered this aspect during the
decision-making process.
 
To answer Eric's question as to why add a check==bloat:
my suggestion was based on the premise that we could with very small
cost
make the behavior of Corinna's test case friendlier.  Rather than
getting potentially random failures (the random values on the stack will
make a
difference in how the test case actually runs), the output would make it
easier for the developer to find their problem.  That is, deterministic
failure is far easier to debug than random.  Admittedly, this would
be for those cases when gcc -Wall were somehow not available (nor used,
etc.).  In general I am willing to pay small--but not large--amounts of
code size for easier problem detection for when I've made stupid
mistakes.
I don't have a strong opinion either way on this particular case, as
most of the time--as Eric points out--gcc -Wall will catch it.
 
Craig

-----Original Message-----
From: newlib-owner@sourceware.org [mailto:newlib-owner@sourceware.org]
On Behalf Of Eric Blake
Sent: Wednesday, November 25, 2009 8:09 AM
To: newlib@sourceware.org
Subject: Re: printf field width argument handling

According to Corinna Vinschen on 11/25/2009 1:50 AM:
> I don't think we have to return with errno set, either.  I'm not even
> sure if we should change the behaviour at all, given that practically
> all BSD-based systems behave that way.

POSIX is explicit that use of an improperly formed specifier (such as
%**s) gives unspecified results; it permits but does not require failure
with EINVAL, and returning successfully after printing an extremely huge
field width still qualifies as a valid action for unspecified results.
Besides, an invalid string is something you can audit for (after all,
gcc
- -Wall catches this particular one if you did it via a compile-time
string,
and if you are using arbitrary user input as a runtime-provided format
string, you are already vulnerable to %n exploits), so why bloat the
code
to stop the user from doing something they should have already prevented
at compile time?

- --

Eric Blake             ebb9@byu.net