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