Re: POSIX requires checking all *printf return values?!?

[Eric Blake]

Let's get the Austin group opinion on this.

According to Jim Meyering on 10/19/2007 9:08 AM:
> Andreas Schwab <address@hidden> wrote:
>> Jim Meyering <address@hidden> writes:
>>
>>> Could it be a bug in printf for failing, yet not setting the
>>> stream-failure indicator that is checked by close_stdout's ferror?
>> A failure from printf does not necessarily mean an output failure.  It
>> can also be ENOMEM or EILSEQ, which are unrelated to output.
>
> I've been looking at the standard to see where it specifies this.
> While the fwrite description is quite clear that the "error indicator"
> is set for write errors, the section describing printf and fprintf:
>
>   http://www.opengroup.org/onlinepubs/000095399/functions/printf.html
>
> doesn't even mention the error indicator.  Not directly, anyway.
> However, it *does* refer to fputc for error conditions.
> The description of fputc clearly states that upon error, it *shall* set
> the error indicator, and that it may fail if ENOMEM:
>
>     RETURN VALUE
>     Upon successful completion, fputc() shall return the value it has
>     written. Otherwise, it shall return EOF, the error indicator for the
>     stream shall be set, and errno shall be set to indicate the error.
>
>     ERRORS
>     ...
>     The fputc( )   function may fail if:
>     [ENOMEM]
>
> I'm beginning to wonder if this is an error in the C library after all.
> Surely POSIX doesn't intend to require that all programs test every
> *printf return value.  That would be silly.  If so, what's the point
> of the stream error indicator?

Personally, I would LOVE for the stream error indicator to be reliable
after [f]printf failures, even in the face of errors unrelated to
fputc()-style actions.  But I don't see that required in the standards,
and this thread was started by a libc implementation that did just that -
returned -1 for ENOMEM without adjusting ferror().  Is it worth changing
POSIX to require ferror() to be reliably set?  Or is it at least worth
adding a note to warn the user of this scenario of ferror() not being set
even when the function returned a negative value?

-- 
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden