On Thu, Apr 29, 2010 at 8:49 AM, Juan Jose Garcia-Ripoll juanjose.garciaripoll@googlemail.com wrote:
I see. What's the rationale? Could ECL's FOREIGN-FREE/ALLOC use plain malloc()/free()?
But why? As we said there is nothing in the CFFI specification that mandates use of malloc(), just that the memory will not be freed
Right. The CFFI specification/documentation is a work in progress though. I believe one of UFFI's major shortcomings is that it fails to ensure consistent behaviour across implementations for error situations. CFFI is much better in that regard, but it certainly could use more work. The issue of whether FOREIGN-FREE/ALLOC should be implemented in terms of malloc()/free() is one such example.
Current system uses the same foreign memory manager as ECL, because it is safer for us, allows a good coexistence of both sets of memory and allows us to keep track of the amount of memory used. Furthermore, should it be needed, some pointers can be allocated as collectable and automatically reclaimed by our GC -- not that it is done by default, though
I'm convinced. :-) I'll update the manual to be explicit about this. Using DEFCFUN to get at malloc()/free() should be straightforward anyway, except we don't have a size_t type.
Also, except for OpenMCL I see no explicit use of malloc/free anywhere. It must be some kind of accident that it works with other implementations.
SBCL calls malloc/free under the hood, as do most other implementations. I think Allegro uses a different allocator.