[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: POSIX requires checking all *printf return values?!?
From: |
Jim Meyering |
Subject: |
Re: POSIX requires checking all *printf return values?!? |
Date: |
Fri, 19 Oct 2007 19:30:56 +0200 |
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?
- Re: printf produces no output for %f directive, (continued)
- Re: printf produces no output for %f directive, Jim Meyering, 2007/10/19
- Re: printf produces no output for %f directive, Andreas Schwab, 2007/10/19
- Re: printf produces no output for %f directive, Eric Blake, 2007/10/19
- Re: printf produces no output for %f directive, Jim Meyering, 2007/10/19
- Re: printf produces no output for %f directive, Jim Meyering, 2007/10/19
- POSIX requires checking all *printf return values?!?, Jim Meyering, 2007/10/19
- Re: POSIX requires checking all *printf return values?!?, Pádraig Brady, 2007/10/19
- Re: POSIX requires checking all *printf return values?!?, Jim Meyering, 2007/10/19
- Re: POSIX requires checking all *printf return values?!?, Andreas Schwab, 2007/10/19
- Re: POSIX requires checking all *printf return values?!?, Eric Blake, 2007/10/19
- Re: POSIX requires checking all *printf return values?!?,
Jim Meyering <=
- Re: POSIX requires checking all *printf return values?!?, Eric Blake, 2007/10/19
- Re: POSIX requires checking all *printf return values?!?, Nick Stoughton, 2007/10/19
- Re: POSIX requires checking all *printf return values?!?, Bruce Korb, 2007/10/22
- Re: printf produces no output for %f directive, Pádraig Brady, 2007/10/19
- Re: printf produces no output for %f directive, Jim Meyering, 2007/10/19