[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.
-pete