Paul Eggert wrote: > On 01/04/2013 12:58 AM, Jim Meyering wrote: >> AFAIK, that comment is still valid > > I can put the comment back but I'd like to word it > so that I understand it -- currently I don't. > > Could you explain a bit more about the problem? > First, I just now reread the C99 standard as well > as POSIX-1.2008, and I don't see how either > standard permits fputc to fail without > setting the error indicator. > > Second, if the C standard actually does let fputc fail without > setting the error indicator, then why did we go through > the effort of removing __wur from glibc's fwrite > prototype? If that's really what the standard allows, > then portable code should look at fwrite's return > in all cases, in order to detect write errors reliably.
Hi Paul, You're right. The problem is subtle, and that description predated POSIX 2008, so its fputc reference is no longer relevant. The fwrite spec does demonstrate the problem: >From http://pubs.opengroup.org/onlinepubs/9699919799/functions/fwrite.html RETURN VALUE The fwrite() function shall return the number of elements successfully written, which may be less than nitems if a write error is encountered. If size or nitems is 0, fwrite() shall return 0 and the state of the stream remains unchanged. Otherwise, if a write error occurs, the error indicator for the stream shall be set, [CX] [Option Start] and errno shall be set to indicate the error. [Option End] note the mention of "write errors". >From discussion[1,2], it became clear that failure due to ENOMEM does not constitute a *write* error, and hence does not require that an implementation set the stream error indicator. This originally arose in a couple of contexts. One was with *printf functions in general. This is were I first learned of the oddity, and realized the far-reaching consequences: [1] http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/11611/focus=11626 Another was with snprintf and glibc's still-inferior implementation: http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/13182 While not relevant to fwrite, EILSEQ is another errno value for which a stream function like fputc can fail, but for which POSIX did not require that the error indicator be set. Today, I noticed that the fputc spec seems to be fixed in the POSIX 2008 issue. However, I suspect that some C libraries still fail to set the stream error indicator upon fputc/*print*/EILSEQ failure. --- [2] https://lists.gnu.org/archive/html/bug-coreutils/2007-10/msg00152.html