[cffi-devel] Crashes on X86-64 CLISP

[Hoehle, Joerg-Cyril]

James Bielman wrote:
>By the way, I was looking into writing a regression test for this and
>had problems since we also use FOREIGN-ADDRESS-UNSIGNED to implement
>POINTER-EQ.  Could we be using EQUALP instead for comparing pointers
>(or is the fact that seems to work just a coincidence?)

I was considering adding pointer-eq to the FFI, since even with 32bit, the current cffi:pointer-eq implementation is likely to cons bignums.  So far, every null-pointer test conses a bignum, just to test against 0.

The irony of history is that, the FFI once had FFI:NULL-POINTER-P (sp?).  It was deprecated when the FFI was reviewed to consistently return NIL for NULL.

Later, I added unsigned-foreign-address.  After some thought, I decided I'd let it create a #<pointer> object from 0, instead of returning NIL.  I thought, "if people really want to obtain a pointer with address 0 using this low-level function, let them do it".

Nowadays, CFFI uses these presumably low-level primitives a lot. I.e. the useage pattern differs between programs using FFI and CFFI. The fact that there's an exception to the NIL<->NULL rule means that robust code implementing cffi:NULL-POINTER-P must test both cases, causing duplication of work (and so far, consing).

Solutions:
A Reintroduce ffi:null-pointer-p, not consing.

B Change unsigned-foreign-address to return NIL
 instead of #<foreign-address #x0000000>.
There would be (almost?) no more exception, and null-pointer-p would become equivalent to cl:NULL.

C Implement cffi:null-pointer-p via cl:NULL and don't worry about somebody asking for (unsigned-foreign-address 0) returning something else.  It might work in practice.
There's just the one CFFI testcase (null-pointer-p (make-pointer 0))
(oh, it's been removed).

Comments?

I'm considering A+B, together with pointer-eq.
	Jorg Hohle.