On Fri, Dec 11, 2009 at 12:48 PM, Jon <jon.forums@gmail.com> wrote:

> From http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/22727 in the "Mixing runtime libraries" section the claim that you can mix msft c runtimes if
>
> * If you call ALLOC or ALLOC_N, use xfree and not free
> * Don't call sprintf or printf in an extension, instead use rb_f_sprintf/rb_vsprintf/rb_io_printf
>
> ...does it make sense to change these free's to xfree's (not libffi's dlmalloc?) in ruby-ffi?
>
>
> C:\Users\Jon\Documents\RubyDev\ffi-trunk>grep -Rn " free(" ext
>
> ext/ffi_c/Buffer.c:154:        free(ptr->storage);
> ext/ffi_c/ClosurePool.c:131:        free(memory->data);
> ext/ffi_c/ClosurePool.c:132:        free(memory);
> ext/ffi_c/ClosurePool.c:135:    free(pool);
> ext/ffi_c/ClosurePool.c:218:    free(block);
> ext/ffi_c/ClosurePool.c:219:    free(list);
> ext/ffi_c/libffi/src/dlmalloc.c:678:  free(void* p)
> ext/ffi_c/libffi/src/dlmalloc.c:857:    free(pool);     // Can now free the array (or not, if it is needed later)
> ext/ffi_c/MemoryPointer.c:137:            free(ptr->storage);
> ext/ffi_c/Type.c:162:    free(type->name);
>

libffi and the C extension are being built and linked against the same
CRT version used by Ruby. That poses no risk for cross-CRT memory
allocation and freeing.

If was the case libffi was built with newer version of Visual Studio,
which links to different CRT than Ruby itself, then I would worry to
make the proper transition of all the free calls for xfree.

-- 
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry