Ticket #105 (NULL checks)

[Joshua Juran]

On Dec 31, 2008, at 12:26 PM, Andy Dougherty wrote:

> On Wed, 31 Dec 2008, chromatic wrote:
>
>> On Wednesday 31 December 2008 08:03:31 Mark Glines wrote:
>>
>>> Ok, I've gone and read through RT #49316 and RT #50684.  It  
>>> sounds an
>>> awful lot like attribute_nonnull is an optimization, not a  
>>> constraint as
>>> I had originally thought.
>>
>> If we use -Wnonnull (implied by -Wall), we'll get compile warnings  
>> when we
>> pass potentially null parameters to functions which require non-null
>> parameters.  There may be optimization possibilities there, but I  
>> believe the
>> primary purpose was to get these warnings.
>
> Except gcc can't always detect if the pointers are "potentially null".
> The problem arises when pointers that are not supposed to be null  
> end up
> being null due to a bug elsewhere in the program.  In those cases, the
> attribute_nonnull actually gets in the way by allowing gcc to optimize
> away checks for such buggy pointers.

If you're declaring the function both with and without the nonnull  
attribute in different places, then this is a bug no different than  
any other case of inconsistent prototypes.  But if gcc considers  
nonnull a guarantee (on which it can base optimizations) but doesn't  
deliver on this same guarantee (i.e. forbidding you to pass unchecked  
pointers as nonnull arguments) then that is either a bug in the  
nonnull implementation or the design itself is flawed.

If const was used only as a basis for optimizations but didn't  
actually enforce a contract, it would be equally problematic.

Josh