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
"Vakatov, Denis (NIH/NLM/NCBI) [E]" <vakatov@ncbi.nlm.nih.gov> writes:
> Ian Lance Taylor wrote:
>
>> We should handle must_use_result and warn_unused_result similarly, except that adding a cast to (void) disables the warn_unused_result warning. Perhaps there should also be other simple ways to disable the warn_unused_result warning.
>>
>> This is not a great solution, but I don't see a better way out of the current unpleasant situation.
>
> You seem to be looking for an absolute solution, and there is
> none. You can't do it all on the GCC side alone.
Yes, of course. That was implicit in my suggestion.
> The reasonable (or, "great enough") solution would be to just trust
> explicit developer's void-casting.
>
> Also, 'warn_unused_result' should be enough; there is no need to add
> more levels to this simple paradigm.
The warn_unused_result extension was implemented specifically to catch
security problems. Permitting developers to just add a cast to void
would make it a very weak facility. Of course in one sense we should
trust the developer. But the history of security problems shows that
developers can not always be trusted. Instead, we assume that there
at least one trusted developer who can add warn_unused_result when
appropriate. Then the compiler arranges matters such that other
developers can not easily avoid the warning. Thus security is,
ideally, increased.
Unfortunately this hasn't worked in practice, because glibc and Debian
have combined to make many reasonable compilations, which have no
security issues, run afoul of warn_unused_result. So my proposal is
to change the existing facility to make it be what glibc and Debian
really want, and to provide a new facility which does what
warn_unused_result was originally intended to do.
I would interpret your suggestion as being that we should abandon the
security goals of warn_unused_result, and settle for the weaker
version which glibc and Debian seem to want. Perhaps that is the
correct way to go. But it does not seem so to me.
Ian