Re: Guile FFI: resizable vector problem

Matthew Dempsky <[email protected]> writes:

> Andreas Rottmann <[email protected]> writes:
>
>> The next thing I ran into: Guile has dropped resizable vectors some
>> time ago. A rationale can be found in [0]. The argument seems sound to
>> me, so what about Pika -- won't resizable vectors yield the same
>> problem wrt to threading? For now, I'll just work around that by
>> making scm_set_n_vector_elts() create a new vector.
>
> Pika's FFI will handle resizable vectors and threading fine because
> users never get pointers to the vector contents -- they can only do
> vector-ref and vector-set! operations on them.
>
> Having scm_set_n_vector_elts create a new vector and copy elements
> would be the Right Thing to do for this.
>
OK. Another thing: What about defining SCM_FEATURE_ macros, e.g.:


#define SCM_FEATURE_CHAR_BUCKYBITS 1 /* for Pika */
#define SCM_FEATURE_CHAR_BUCKYBITS 0 /* for Guile Pika FFI */

We can use those in the testcases, to check only for supported
features. This is also usable for applications that want to use the
Pika FFI and use features as available, but still stay portable across
the different FFI implementations.

Andy
-- 
Andreas Rottmann         | [email protected]      | 118634484@ICQ | [email protected]
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Latein ist das humanoide Äquivalent zu Fortran.
   -- Alexander Bartolich in at.linux