Eric Blake <[EMAIL PROTECTED]> wrote: > Let's get the Austin group opinion on this. > > According to Jim Meyering on 10/19/2007 9:08 AM: >> Andreas Schwab <[EMAIL PROTECTED]> wrote: >>> Jim Meyering <[EMAIL PROTECTED]> 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? _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils