[cffi-devel] ECL specific changes for CFFI

[Luís Oliveira]

On Thu, Apr 29, 2010 at 8:49 AM, Juan Jose Garcia-Ripoll
<juanjose.garciaripoll at 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.

-- 
Luís Oliveira
http://r42.eu/~luis/