[gambit-list] ffi and u8vectors, s8vectors, ...

Christian Jaeger christian at pflanze.mine.nu
Sun Jun 3 06:58:00 EDT 2007

Andreas Huber wrote:
> Hi,
> I've been playing around with Gambit's foreign function interface  
> today, and the big stumbling block
> i've hit is that I cannot easily pass u8vectors to native code, i.e.  
> u8vector is not compatible
> with (pointer void) or (pointer unsigned-int8).
> Is there a chance this might be changed in the future?
> I would _not_ want the address of a copy of the bytevector's contents  
> to be passed to c-code but a
> pointer to the original u8vector's storage location instead.

Pass the scheme-object as is. You can then either use the accessor
macros from gambit.h, or cast it's body address to the pointer type
you like.

(define (frobvec vec)
   (if (not ((c-lambda (scheme-object) scheme-object "
    if (___U8VECTORP(___arg1) && ___INT(___U8VECTORLENGTH(___arg1))>=XYZ) {
	char *p= ___CAST(char*,___BODY(___arg1));
    } else {
") vec))
       (error "invalid type of:" vec)))

(Note: I've typed this right into the mail without testing.)

You could also use c-define-type with your own conversion macros to
abstract the check and cast away.

> I am guaranteed that GC will not move my memory for the duration of  
> this foreign call, am I not?
> (unless of course, scheme is reentered from within that native call,  
> in which case all bets are off, right?)

Allocating scheme objects from C code can also trigger the GC.

Note that bigger u8vector's are allocated as still objects and then
will never move. You can check if a memory-allocated object (check
with ___MEM_ALLOCATED(obj) if you don't know if it's memory-allocated)
is a still object with the code (___HD_TYP(___HEADER(obj))==___STILL).


More information about the Gambit-list mailing list