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.
_______________________________________________
cffi-devel mailing list
cffi-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
