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