Comment 18 for bug 305176

Revision history for this message
In , Paolo Bonzini (bonzini) wrote :

> In the case of fwrite, for example, the only obvious case where checking
> would be useless is if you already are writing an error message before
> exiting with error status and so an error writing the error message could
> not usefully be reported anywhere and wouldn't lead to a change of exit
> status.

Not really. The return code of fwrite is not only useless: worse, it gives a *false* sense of security. Stuff can stay in the buffers, only to give errors when you do an fflush or an fclose, which do not have the attribute in glibc (as of July 2007).

It is much better to do

  fwrite (buf, m, n, f);
  if (fflush (f) != EOF)
    perror ("write");
  if (fclose (f) != EOF)
    perror ("close");

than checking the return code of fwrite, and that's more or less what coreutils does. Anyway this is OT, because this would be a glibc bug.

Back to the GCC point-of-view, the situation is similar to setting a format(printf) attribute on a printf-like function that also has some extension. It would work for some calls, maybe most, but not for all of them. So the solution would be to use -Wno-format, either directly or via #pragma GCC diagnostic. This warning is not mandated by any standard, after all.