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.
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
Equipa Portuguesa do Translation Project
http://www.iro.umontreal.ca/translation/registry.cgi?team=pt
_______________________________________________
cffi-devel mailing list
cffi-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
