Hi,
It's the first time I come across CFFI after James Bielmann's initial questions
on CFFI design in June 2005.
I had a short glance at the CLISP implementation and it immediately struck me
that CFFI dislikes CLISP's consistent use of NIL for a NULL FFI pointer. Why?
I find using separate types for NULL and regular pointers extremely beneficial
to programs. The "NIL is not a foreign-address" allows for cheap safety nets,
i.e. my original AFFI (FFI for Amiga-CLISP, design in 1994/95) would error out
when trying to mem-read from a NIL "pointer". The application won't crash.
OTOH, I can understand that native-code compilers prefer homogenous types be
used throughout the code (so i.e. type declarations look simpler, and maybe
compilers like CMUCL's Python can avoid some boxing), but CLISP has been
bytecode for over 13 years, which allows for different designs.
CLISP is very consistent about accepting and returning NIL for NULL pointers,
so why does CFFI go to some length to reintroduce foreign pointers whose
address is 0 instead of just using NIL?
BTW, IIRC my own UFFI-wrapper macros for CLISP, there was no problem at all
with defining
(deftype ffi-kind (or NULL FFI-ADDRSS FFI-VARIABLE FFI-FUNCTION)).
So CLOS slots could have valid :type declarations.
FWIW, it's Bruno Haible whom whoever (James?) wrote a comment about beer in
cffi-clisp.lisp owes a beer for exporting the interface to alignment of foreign
types. It's been there since 1995.
Regards,
Jörg Höhle.
_______________________________________________
cffi-devel mailing list
cffi-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
