Ticket #105 (NULL checks)

Mark Glines mark at glines.org
Mon Jan 5 20:33:45 UTC 2009


Will Coleda wrote:
>> If gcc were doing its job, the asserts wouldn't have caught any of those
>> cases.  It seems like gcc's "contract enforcement" seems to consist of a
>> compile-time check with a warning, and no runtime followup.
> 
> FYI, newer versions of gcc theoretically[0] have a way to promote
> certain warning types into errors. Forcing this to be a compile time
> error on gcc would help trap these issues much sooner.

Well, that sounds great, for the portion of these issues that are 
possible to detect at compile time.  The problem is, gcc can't do a very 
good job of this at compile-time, so it doesn't catch a large number of 
cases.

Without a *runtime* check, I think the best gcc is ever going to be able 
to do is issue a warning (or error) every time a NULLOK function calls a 
NONNULL function without checking for and handling the NULL case in some 
other way.  This is similar to the warnings you get when a function with 
a const argument passes it to a non-const function.

With that in mind, if gcc were to do it right, I think it needs to 
generate some runtime checks for cases where it couldn't be sure at 
compile time.  We're doing runtime checks for ourselves now, but having 
this done within the compiler would make it possible to put the caller's 
filename and line number in the error message, rather than the called 
function.  That seems more useful to me, in general.  (And I looked into 
several kinds of tricks, weird macro wrappers and inline functions to 
get that with the headerizer assert stuff, but couldn't find a good way 
to do it.)

Mark



More information about the parrot-dev mailing list