[Larceny-users] boxed vs. void* in the Larceny FFI on Windows

[Felix Klock]

David-

On Jul 22, 2007, at 6:08 PM, David Rush wrote:

> But the documentation is ... weak ... as I think is widely
> acknowledged. SO can someone tell me what the difference is between
> boxed and void* in the (require 'std-ffi) layer? *And* how to pass a
> null pointer to a call-out in a reliable fashion? And if you;re going
> to point me back at the docs can you clue me in as to which specific
> ones? There are clearly pieces of documentation from several different
> FFI eras in the source tree and it is difficult for me to tell which
> applies where.

I'll write up a more complete answer to these questions later and  
incorporate it into the docs, but I thought you'd like a quick answer  
now.

A parameter of the 'boxed' type is meant to be a structured Scheme  
object (a cons cell, or a vector, or a bytevector).  The invoked  
function is then passed a pointer to the data in the object; so for a  
vector or bytevector, the foreign function will be passed an address  
that is immediately *past* the header for the object, and for cons  
cell, the foreign function is passed the address of the cons cell  
itself.  I do not think that the boxed type is actually terribly  
useful unless you're invoking a function that knows that it is  
dealing with Larceny runtime objects.

A parameter of the 'void*' type is meant to be an address of  
explicitly allocated memory on the C heap (*not* managed memory the  
Larceny heap).  One might argue that an int parameter would do just  
as well, but I found that passing int's all over the place led to  
fragile code when I was experimenting with making bindings for GTK.   
The void* type is kept in an opaque structure that you can extend  
with specific subtypes (another artifact of my experiments with  
writing bindings for GTK).

To pass a null pointer as a parameter declared as 'boxed' or '(maybe  
void*)', I pass #f.  The void* type doesn't support null pointers  
(again an artifact of my GTK experiments; I wanted to be able to  
express in an interface to a foreign function that null pointers are  
not accepted by a particular function); that's why you have to use  
the 'maybe' unary type constructor.

-Felix