[cffi-devel] Type Translators and Callbacks

[James Bielman]

On Tue, 2005-11-15 at 15:17 +0000, Luís Oliveira wrote:

> Or we could define yet another kind of translator, say :CALLBACK-TO- 
> C, that would normally inherit from :TO-C and that in :string's case  
> would use malloc. (hmm, this gives me some ideas on how to rewrite  
> the type system.)
>
> Also, the same applies to foreign variables.

Well, I don't see the point of using a separate translator for callback
return values versus setting foreign variables.  If I understand :TO-C
correctly, it is used when we have a Lisp value we need to convert to a
C value with indefinite extent, which is the situation in both those
cases.

The more I think about it, the more I like just specifying the built-in
type translators for aggregate objects (which is just :STRING, right?)
allocate their memory using malloc in the :TO-C case.  I can't see any
real good reason not to.

If I had an existing string I wanted to pass from a callback I would
just declare it to return :POINTER instead.  (What happens if you return
a pointer from a function with a result-type of :STRING?  Should it pass
it unmodified or malloc a copy?)

> I think that WITH-FOREIGN-STRING, WITH-FOREIGN-OBJECT and WITH- 
> FOREIGN-PTR should take a :MALLOC option, as should FOREIGN-ALLOC,  
> etc... I have thought about this before, probably because CLISP does  
> this IIRC.

Yes, that sounds like a good idea.  Then we could document that
the :TO-C translation for :STRING uses (FOREIGN-STRING-ALLOC :MALLOC T).

James