This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: C++ and Java CNI: Check Java references


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]