[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] Re: Structs

From: Peter Keller
Subject: Re: [Chicken-users] Re: Structs
Date: Tue, 15 Oct 2002 22:59:54 -0500
User-agent: Mutt/1.2i

On Tue, Oct 15, 2002 at 09:18:23AM +0200, Felix Winkelmann wrote:
> Because the result-type of `z_stream-next_in' is
> a c-pointer (number-vectors are not allowed as return-
> type), but you pass an u8vector when storing the
> value in the field, which gets converted into a char*.
> Additionally, GC will invalidate the pointer (as you
> correctly pointed out in your previous mail.

So then, you're saying that even a simple structure like this:
struct foobar
    int *data;
    int num_elems;
    int touched;

can't ever have an interface in chicken such that this code is valid:

(let ((f (make-foobar (s32vector 1 2 3 4) 4 0)))
    (Cfunc_add_one_to_elems f) ;; increment touched in this function too
    (Cfunc_add_one_to_elems f) ;; increment touched in this function too
    (print (foobar-data f) " " (foobar-num_elems f) " " (foobar_touched f)))

results in:
s32#(3 4 5 6) 4 2

That seems a pretty severe limitation--not counting the fact that if it
did work, the C function couldn't modify the pointer in the structure to
say point to newly allocated memory. Structures are the bread and butter
of C interfaces and I think that warrants true support for them if you
want to have a practical C FFI. Otherwise, it will be a nightmare amount
of specialized handwritten and inefficient code to implement something
like the above.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]