On Sat, May 29, 2010 at 3:13 AM, Dave Korn <dave.korn.cyg...@gmail.com> wrote:
> On 29/05/2010 01:17, Ian Lance Taylor wrote:
>> Dave Korn <dave.korn.cyg...@gmail.com> writes:
>>
>>> On 28/05/2010 22:25, Ian Lance Taylor wrote:
>>>
>>>> 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.
>>
>> These statements are too strong.  Of course programmers can outwit any
>> such techniques.  But these techniques can still catch real accidental
>> mistakes.  It's simply false to say that dumb-minded static analysis
>> isn't any use at all.  E.g., identifying and removing calls to the
>> standard gets function is a simple and completely appropriate
>> technique for increasing security.  Simple static analysis doesn't
>> solve all problems, but it does not follow that it isn't any use.
>
>  Yes, of course that's true, I was certainly being hyperbolic for effect :)
> But doesn't that really argue that there should always be an override
> mechanism?  I think we're straying from compiler-warning into lint territory 
> here.

No, we only provide means to mark functions in a way and unconditionally
warn.  We can't control how the attribute is used and the attribute was
_designed_ to be non-overridable.  We shouldn't change semantics of
an attribute.

Similar issues exist with the nonnull attribute, which when not carefully
used will even result in miscompilations, not only false warnings.  And
we've repeatedly closed bugreports about this as invalid.  So should
we do for invalid or inappropriate users of warn_unused_return.

Richard.

>    cheers,
>      DaveK
>
>
>

Reply via email to