Re: on coding a portable R6RS package supporting Guile and its FFI

[Daniel Hartwig]

On 27 January 2013 23:08, Ludovic Courtès <address@hidden> wrote:
> Hi Marco,
>
> Sorry for the delay.
>
> Marco Maggi <address@hidden> skribis:
>> * It appears  that there  is no  facility to  handle "output
>>   arguments" from  C functions; I  mean the cases where  a C
>>   function accepts  as argument  a pointer to  variable that
>>   will be  filled with  some computed value.   I am  using a
>>   WITH-LOCAL-STORAGE[4]  macro  which  is  maybe  ugly,  but
>>   works.
>
> I typically roll my own allocation and dereference routines as well,
> such as ‘make-int-pointer’ and ‘dereference-int’ at:

Likewise.

>
>   
> http://git.savannah.gnu.org/cgit/libchop.git/tree/guile2/chop/internal.scm#n255
>
> Perhaps adding them to (system foreign) would help?

Yes, in these generic cases.

>
>>   Such  arguments are  common, and  represent a  nuisance to
>>   handle.  Racket has a sophisticated interface, complicated
>>   to use  when writing adapter code.  Something simpler but
>>   built in would be useful

Pointer arguments are common, yes, but they have a variety of usage
patterns across different APIs.  This is evident in the complexity of
the Racket API for dealing with this.

In particular, the questions of who (caller or callee) allocates the
memory and who deallocates the memory complicate the handling.  In
some APIs, the party in control of deallocation can change.

>>  (this is the sort of thing a user
>>   does  not want  to think  about: it  should be  an already
>>   solved problem).

Mapping any pointer interface requires some user thought to consider
its unique behaviour.  It is risky to abstract some of that process
away from the programmer, even if only to accomodate a single, “most
common” usage.

IMO the best that could be done without complicating the FFI is to
bring in a small set of generic helpers such as Ludo's
make-int-pointer, etc..

> …
>
> All in all, it’s always seemed easier to me to do that manually, with
> helpers specifically adapted to the C library I write bindings for.
>
> WDYT?

Right.  After considering the requirements for any given interface it
is only a small amount of work to create the appropriate helpers.
Being specific to the API under consideration, such helpers can
present an optimal interface.

>
>> * Whenever  a callout  to C  accepts a  pointer argument:  a
>>   bytevector argument  is rejected.   Is this not  a useless
>>   complication?

No, it is sensible type checking: bytevector is not pointer.

>>
>>   One   can    work   around   it   by    explicitly   using
>>   BYTEVECTOR->POINTER, so everything is ready in Guile.  The
>>   other  Scheme   implementations  using   a  non-compacting
>>   garbage collector already support  this feature and I find
>>   it truly convenient.
>
> Well, the ‘pointer’ type is useful, because it’s inherently a more
> low-level representation than bytevectors.
>
> That said, the FFI call could implicitly convert bytevectors to
> pointers.  However, I generally prefer avoiding implicit type
> conversions like these, for clarify.
>
> Thoughts?

This implicit conversion must be avoided.  Instead, how about
supporting supporting SRFI-4 types (s16vector, etc.) or typed arrays
in the FFI.  This would only cover some use cases, where the caller
controls the memory and the foreign argument is a /typed/ pointer.
This much could be implemented without seriously complicating the FFI.

For “void *” it is still required to explicitly pass a pointer object,
though it is not difficult to create helpers appropriate to the
/particular/ interface.

For callee allocated or deallocated memory it is still required to
interface using pointer objects.

SRFI-4 has the advantage that slots are always stored contiguously in
memory.  Typed array slots can be stored non-contiguously, and any
such array would have to be rejected as “array-contents” does.

Regards