|
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.
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
[Prev in Thread] | Current Thread | [Next in Thread] |