This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Request for suppressing "warn_unused_result" warnings
On Fri, May 28, 2010 at 11:32:46AM -0700, Ian Lance Taylor wrote:
> Please read http://gcc.gnu.org/PR25509 .
>
> As the compiler documentation states, warn_unused_result was intended
> for cases where failing to check the return value is always a security
> risk or a bug. The documentation cites the example of realloc. That
> is a case where casting the return value to (void) would always be
> wrong. The compiler really should warn for that code by default; if
> you have some crazy need to ignore the result of realloc, just use the
> -Wno-unused-result option.
>
> That said, I agree that glibc is overly aggressive in using
> warn_unused_result when FORTIFY_SOURCE is defined. I agree that
> Debian is overly aggressive in having a distro-specific patch to
> enable FORTIFY_SOURCE by default. I think that both of those
> decisions were ill-advised. The combination of those decisions with
> the ones made by the gcc developers definitely makes some code
> inappropriately awkward.
>
> So what are the right choices here? I tend to be reluctant to endorse
> adding a new option, but I can't think of another approach.
Perhaps we might have a pragma to avoid a specific occurrence of the warning.
So the example code would become:
extern int foo() __attribute__((warn_unused_result));
int main()
{
/* the pragma has effect only on the following statement */
#pragma GCC dont_warn_unused_result
(void) foo();
return 0;
}
Or perhaps even
_Pragma(GCC(dont_warn_unused_result), foo())
I know that pragmas have been undesirable in GCC, but perhaps in that
case (marking a specific occurrence or statement) they might be
ok. AFAIK, we don't have statement attributes.
Or perhaps it should be yet another builtin, eg
builtin_dont_warn_unused_result(foo())
An artificial, contrieved, hypothetical use case could be when the
programmer know for sure that a particular call occurrence to a
warn_unused_result function don't return normally (e.g. always throws
a C++ exception or do a setjmp in C or loop forever.).
But I agree that all this is not very important. Sorry for bothering!
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***