Re: Exposing common type wrapping/unwrapping methods

[Ken Raeburn]

On Aug 20, 2005, at 08:40, Marius Vollmer wrote:
> My decision at that time was that we assume that there is only one
> malloc and one free.

Okay.

> > Basically, malloc and free referenced from a DLL, say libguile.dll,
> > may be different instances of the functions than the application or
> > other DLLs might see, and they should thus be assumed to have
> > different allocation pools that can't be mixed.
>
> Is this merely technically possible or are people actually using this
> 'feature'?  Is it considered a godd practice?  Why should we agree?
>
> Can we require libguile.dll to use the systems libc malloc and free?
> We could put this in the documentation then so that people know which
> variant of malloc and free to use together with libguile.dll.

I'm not an expert in this area, but my understanding is:
"The system's libc" is part of the problem here -- there's no special  
DLL which is *the* C runtime library.  You can use MSVCRT.DLL, or  
MSVCR71.DLL, or MSVCRTD.DLL, and perhaps others, depending on the  
compiler, compiler version, and compiler options you use for each  
component.  You can also link the C runtime into your executable, but  
its symbols may not be seen by the DLLs, I think.

It's all well and good if you can tell someone that they have to use  
the same compiler and options for building the executable as for  
building the library, but it gets messy if someone might be providing  
a pre-built DLL.

Ken