Ticket #105 (NULL checks)

[Nicholas Clark]

On Wed, Dec 31, 2008 at 01:40:14PM -0800, Joshua Juran wrote:

> 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.

It's also valid to link object files produced by different compilers (or even
languages). So one could have a function defined in a header file with nonnull
constraints that are made invisible to a non-GCC compiler (so that it compiles
at all), and the code compiled with that non-GCC compiler happens to violate
the constraint.

However, there's a much bigger problem:

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

This is a good analogy. Unless I've missed something big, the implementation
in gcc is seriously half-baked. One is only able to annotate pointers in
function parameters as nonnull. It is not possible to declare pointer
variables or pointer structure members as nonnull. Hence any assignment of
NULL to a variable, and subsequent passing of that variable to a function
can't and won't warn.

It's as if one could only use 'const' on function parameters, not on variables
or structure members. And that assignment of const constrained function
parameters to variables or structure members did not (could not) warn. Hence
all such assignments would implicitly be casting away const.

Until gcc fixes that (has it?), nonnull can't be relied on to be truthful.

Nicholas Clark