[cffi-devel] Re: cffi/allegro crash

[Luís Oliveira]

On 12/19/05, Hoehle, Joerg-Cyril <Joerg-Cyril.Hoehle at t-systems.com> wrote:
> b) Users should be pointed at the problematic string <> NIL <> pointer conversion. That's a requirement for documentation of CFFI/UFFI.
> c) Use of NIL in CFFI or UFFI is declared non-portable in the documentation.
[...]
> e) Such a "pointer" may well be represented as NIL on the Lisp side. Nevertheless its opaque.

Hmm...


> f) CFFI and UFFI must export a type for the pointer types they use that is suitable for use with type declarations. -- a TODO for CFFI
>    Example: (deftype pointer #+allegro number(?) #+clisp(or ffi:foreign-address ffi:foreign-variable ffi:foreign-function null))

I've wondered about this before. This sounds like a good thing to add
to the various cffi-sys implementations.

> g) This type cannot be used for discrimination (by this I mean that the CFFI/UFFI documentation specify this property).  That is (typep foo 'pointer) does not mean that foo is nothing but a pointer.  It could be an integer in Allegro, etc.

Allegro does provide an alternative representation for pointers, I
guess we should use that unless there's some performance issue.

> j) Only acceptable exception to h): Provide a new (non-default) pointer type that does null-pointer-p <-> NIL (or whatever else the user chooses) conversion.  Such a thing has its uses.  Another useful candidate for post-transforms is the "return-type is mostly unsigned int, except for -1" pattern. E.g. read() and the like. -1 is awful as an unsigned int, and using a signed int when its mostly unsigned also feels wrong.

Let me see if I got this straight, your proposal is that the :pointer
type may or may not accept NIL (but it should documented as
non-portable), and that we should provide a second pointer type that
is guaranteed to translate between the null pointer and NIL.

If this is what you mean, I disagree. 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.

IMHO, one of biggest drawbacks of UFFI (one that I found while testing
uffi-compat on a couple of libs) is the lack of uniformity. For
example, in libs primarily developed on lisps with typed pointers (eg:
SBCL), many (a few?) operations had bogus types and these bugs didn't
show up in these lisps but caused errors on others (and uffi-compat,
with whatever lisp).

--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt