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 28/05/2010 22:25, Ian Lance Taylor wrote:
> "Vakatov, Denis (NIH/NLM/NCBI) [E]" <vakatov@ writes:
>> 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.
But it's a weak and fundamentally flawed facility in the first place.
Permitting people to *believe* they can rely on it would be just as bad as
permitting explicit loopholes.
> the history of security problems shows that
> developers can not always be trusted.
Yeh, but it also shows just as surely that dumb-minded static analysis isn't
any use at all.
> 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.
My proposal is that we acknowledge that we have two different classes of
users here, whose interests are different, and that we don't take sides in any
conflict between them.
> abandon the
> security goals of warn_unused_result
I honestly don't believe it has any (achievable) security goals. I don't
see how it's any more useful than grepping for 'strcpy' and saying 'Hey that
could be a bug'.
Also, if anyone wants to stand by this at all, then they are obliged to take
the attitude that Paolo's original proposed workaround:
>
> I suggest that you add two functions like these:
>
> static inline void ignore_value (int i) { (void) i; }
> static inline void ignore_ptr (void* p) { (void) p; }
>
> that you can use instead of the (void) cast.
... is in fact a bug that should be fixed. The return result from the
function is still ignored, after all.
cheers,
DaveK