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

[Jim Meyering]

Eric Blake <address@hidden> wrote:

> 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

How about *allowing* ferror to be reliably set?

> adding a note to warn the user of this scenario of ferror() not being set
> even when the function returned a negative value?