On 2005-nov-15, at 06:28, James Bielman wrote:
As Luis's comment in the C code portion of the callback tests indicates, C code that calls this callback has no reliable way to deallocate the memory allocated implicitly by the type translator. The only way to deallocate it is from Lisp via FOREIGN-STRING-FREE.
I think this is probably not too bad if we document it very clearly, but it worries me. Making type translators not apply to the return value of callbacks would remove the possibility for a non-obvious memory leak here.
Another option might be a :malloced-string type with a :TO-C translator that explicitly malloc's the buffer---or just specify that FOREIGN-STRING-ALLOC always uses malloc, I suppose. Obviously that wouldn't apply to possibly stack-allocated strings allocated by WITH-FOREIGN-STRING...
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.)
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.
Also, the same applies to foreign variables.