[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Exposing common type wrapping/unwrapping methods

From: Ken Raeburn
Subject: Re: Exposing common type wrapping/unwrapping methods
Date: Sat, 20 Aug 2005 09:53:28 -0400

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.


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]