[cffi-devel] must cffi-sys::with-pointer-to-vector-data go?

James Bielman jamesjb at jamesjb.com
Wed Jan 25 19:30:33 UTC 2006


"Hoehle, Joerg-Cyril" <Joerg-Cyril.Hoehle at t-systems.com> writes:

> cffi-sys::with-pointer-to-vector-data, as is, is highly problematic.
> Trying to get the base address of a Lisp vector in memory is
> unportable and subject to subtle errors with a moving GC.  I'll try
> and suggest a better API below.

I think you make a lot of good points here, and I mostly agree with
your conclusions about using the block interface instead.

I had another idea though---what if, instead of WITH-SHAREABLE-VECTOR
or whatever, there was a CFFI VECTOR foreign type with an appropriate
type translator to allow passing a Lisp vector as a pointer to a C
function?  Something like (just making up syntax as I go along here):

  (defcfun ("read" unix-read) :int
    (fd :int)
    (buffer (vector (unsigned-byte 8) :out))
    (bufsize :long))

The VECTOR type translator would now have enough information to safely
disable the GC, pin the vector, or whatever is necessary only during
the duration of the foreign function call.  And since we know the
direction (and presumably it would be required) we can do the correct
copy in or out on Lisps that can't do the optimization.  I don't know
how this would work on Allegro though if a vector _must_ be created in
a static area in order to do this.

Obviously all bets are off if the vector isn't big enough, etc, but
that's the risk you take when you call C functions anyway...

Thoughts?

James



More information about the cffi-devel mailing list