C++ and Java CNI: Check Java references

Per Bothner per@bothner.com
Mon Apr 23 22:12:00 GMT 2001


Tom Tromey <tromey@redhat.com> writes:

> What are the alternatives?
> 
> We could require explicit null-pointer checking in all CNI code.
> 
> However, explicit checks are redundant when we have a SEGV signal
> handler.  So then we could make the checks conditional.

So having the compiler automatically insert the checks when a SEGV
handler is available *and* the check is useful is nice.  But many
or most of the checks would probably be a useless or redundant,
but the compiler cannot determine that. In those cases inserting
the automatic checks is losing.  So I don't know what the answer is.
> 
> But explicit checks, whether conditional or not, are hard to maintain.
> It is easy to add new code which needs a check, without adding the
> check itself.  I see it as being like the `GCPRO' requirement in Emacs
> -- missing checks are a continual source of bugs.  Now, in this case,
> it isn't as bad as Emacs, since a missing check will simply cause a
> crash.  That would be fine if we believed that testing could uncover
> all such crashes.

That is a good argument for inserting the checks.

One rather blue-sky idea is to allow a programmer to annotate
variables (including parameters, fields, and array elements) to
indicate they should never be null.  This would be an extended type
specification, at the Java level, not the CNI level, and is a special
case of data type invariants.  Such invariants can be checked in
"safe" mode, and assumed in "fast" mode.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/



More information about the Java mailing list