[Bug c/25509] can't disable __attribute__((warn_unused_result))

["joseph at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #19 from joseph at codesourcery dot com  2008-10-17 16:55 -------
Subject: Re:  can't disable __attribute__((warn_unused_result))

On Fri, 17 Oct 2008, bonzini at gnu dot org 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.

Yes, I previously noted this as an alternative valid style in comment#6. 
glibc has chosen to make one style much easier than the other and that's a 
matter for the glibc maintainers, not for GCC to work around glibc.

> 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.

Yes, all warnings in GCC should have options to control them as a general 
principle of warning control, but some (such as in this case) would be 
there more for a general principle than because they should actually be 
used.  GNU software should not be working around other GNU software; if 
some GNU software has a problem with attributes used in glibc then in the 
first instance the maintainers of both packages should try to ensure that 
glibc's headers and the other software's coding style work well together.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509