cl-test-grid results for svn revision 14755

Massimiliano Ghilardi massimiliano.ghilardi at
Sat Apr 11 13:13:23 UTC 2015

On 04/11/15 09:59, Mark Evenson wrote:
> On 2015/4/8 20:13, Massimiliano Ghilardi wrote:
> […]
>>> Only I am surprised that LispObjects can be null: is it allowed, and
>>> when can it happen?
> As far as I can determine, LispObject references should never be null
> when being passed as an argument to a Java function, but the code base
> is inconsistent (buggy) on this point.


> As for your question on "whether ABCL is really supposed to pass null
> LispObject references to the Java implementation of primitive types", I
> think the answer is negative, as a Java primitive type by definition
> cannot hold a null reference.  This disjunction from java.lang.Object is
> what "makes" it a primitive type.  Our codebase is riddled with the
> assumption that accessing a LispObject won't return a null, as in the
> location your [test case failed][1]:
>      if (!value.equalp(ht.get(key))) {
>        return false;
>      }
> Here, ht.get() should not return a null reference to be chained into the
> value.equalp() call no matter what the value of 'key' turns out to be.
> In lieu of something like a comprehensive audit, we are unfortunately
> left fixing these problems on a case by case basis.

 From what I saw, ht.get(key) returns Java null if key is not present in 
the hash-table. I agree this is a case of
"the code base is inconsistent (buggy) on this point".

On the other hand, let me change my mind and tell this:
I find it non-obviously useful, although contorted.
Since Java null is not a valid LispObjects, it can represent "failure",
as in the case "key not present in hash-table", without having to use
multiple values.

For example, for a EQUALP hash-table, "value.equalp(ht.get(key))"
exactly means "hash-table ht contains the pair key/value"

If ht.get(key) is modified to return a valid LispObject (for example 
NIL) to mean "key not found", the code "value.equalp(ht.get(key))"
will become bugged for value == NIL.
Fixing it requires ht.get(key) to return multiple values. The code 
"value.equalp(ht.get(key))" would become more complicated, probably 
something like:

LispObject v = ht.get(key);
LispThread.currentThread().getValues()[1] != NIL && value.equalp(v);

> But perhaps I have misunderstood your question somewhat:  is there
> something more specific you were referring to?

I was asking the same question you already answered above.

Just I realize "primitive types" is misleading, as I meant "types 
defined by the Common Lisp standard and implemented in Java by ABCL",
not "Java primitive types".

> [r14757]:
> [1]:



More information about the armedbear-devel mailing list