[cffi-devel] Re: cffi/allegro crash

[Hoehle, Joerg-Cyril]

Luis Oliveira writes:
>I think the behaviour here
>should be uniform since ideally users would test a set of CFFI
>bindings on one implementation and be confident that it would work on
>the other supported lisps.

We all agree on that.  However, how do you expect to prevent a long-time Allegro user to inadvertently write 0 instead of (cffi:null-pointer)?

This is exactly the same with CLISP+Lispworks with NIL.

We don't have static typing in CL, or at least, not without a cost.  Strong typing is all we have.

I suggest the solution is NOT to add (check-type x ...) but to leave the individual FFI's as is.
Allegro must have a reason to stick to integers, even though it's over 10 years that I criticized it the first time :-)

BTW, CFFI reinvented the pattern "normal+other-as-different(e.g.NIL)-type" with :string. See foreign-string-to-lisp etc.  It's a nice pattern, indeed.  Why fight it for :c-pointer, but accept it for :string?


But here, I'm not arguing in favour of a NULL->NIL conversion. I'm in favour of leaving the respective implementation's FFI as is, and not generate code for CLISP to turn NIL back into a pointer with a 0 address.  I agree that I wouldn't argue with that much heat if this were not related to performance.

I believe that if somebody wanted a higher expectation for portability, then s/he might use a "debug converter", which would turn every pointer into a CLOS instance that CFFI would then somehow typecheck at run-time.  Obviously, that should be a debug aid only, and not for general code.
Similarly, I have a uffi:def-foreign that'll do nothing but type-check at compile (macro expansion) time.  I found several bugs in libraries using UFFI this way.

Regards,
	Jörg Höhle.