Re: Guile FFI: resizable vector problem

    > From: Andreas Rottmann <[email protected]>

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

This makes sense for the "first plan" -- extracting a "portable FFI"
from the Pika native FFI, and supporting that portable FFI as a way to
write extensions to Guile.

I think that initially, the portable FFI should not deal with
buckybits at all.   If C code says to Scheme "Hey, gimme that
character converted to a C value", and the character happens to have
non-0 buckybits, then Scheme should reply "Sorry, can't do it."

The rationale for that is that so few implementations deal with
buckybits that they are a low priority for a portable FFI.   At the
same time, many implementations will have _some_ kinds of characters
that aren't easilly converted to C values in a portable way -- so the
possibility that asking for a character can return an error is worth
building in to the portable FFI.

-t