Re: [avr-libc-dev] [RFC] Joerg's new vsprint functions.

[Theodore A. Roth]

On Wed, 19 Nov 2003, Mike Panetta wrote:

> On Wed, 2003-11-19 at 15:04, Theodore A. Roth wrote:
>
> > I'm still far from grokking all of the stdio voodoo. ;-)
> >
> > Are you satisfied with this for 1.0 then?
>
> Actually no.  After looking at the code one more time, it can fail if
> the char buffer is NULL. vs(n)printf(_P) never checks if s is NULL.  Nor
> does fputc check if stream->buf is NULL before using it.  But even if it
> did (or if the call to vfprintf(_P) above it did), then there would
> still be a problem, because vfprintf would (hopefully) return -1, and
> this line in vsnprintf would fail:
>
>       s[i < f.size? i: f.size] = 0;
>
> vsprintf would probably have a similar problem, but I am not sure how
> stream.len is handled if the lower level code returns an error (it
> currently does not in this case though).
>
> It seems that nowhere in vfprintf.c is the return value of putc checked
> (even for EOF), so this may be a moot point...  But there is still the
> chance of someone passing vs(n)printf a null buffer and not knowing why
> it crashed.  I think the most efficient place to check for null would be
> in the fs(n)printf(_P) call itself.  It would also make it so you did
> not have to modify any code below it :) BTW, while I am at it, I looked
> at the code from s(n)printf and it has the same problem.  It may have
> been inherited via cutNpaste.
>
> If you want call me pedantic and commit it anyway, as other then the
> null problem it seems to function fine (its almost identical to the now
> working s(n)printf(_P) code anyway) that would be ok I guess ;).

A similar problem has been noted for printf() and printf_P() in bug
#6141.

It looks like we need to add quite a few sanity checks. :-(

I don't know wether to commit for 1.0.2 or to defer until we address the
problem.

Anyone else have any input?

Ted Roth