From: "Daniel Stenberg" <daniel_at_haxx.se>
Sent: Wednesday, September 18, 2002 11:01 PM
> libcurl uses malloc() to allocate memory and simply requires free() to
free
> it again. That is how C works. That is defined in standards written
decades
> ago.
>
> That is not inconsistent.
>
> The fact that Windows, or at least MSVC++, commits very ugly deeds and
> redefines what malloc() and free() do, depending on which compiler flags
you
> use, doesn't make libcurl inconsistent.

It's really evil on MSVC. You have *THREE* different versions of the runtime
library (thread-unsafe static link, thread-safe static link, and linking
against MSVCRT60.DLL). These three have two versions each - 'Release' and
'Debug'.

Combined with "DLL hell", the linking side of building and distributing
Windows programs is incredibly unpleasant. My solution? Build all third
party libraries myself and link statically. There's no benefit to using DLLs
if you can't count on them being shared amongst applications (which you
can't - would YOU trust a DLL randomly thrown into c:\winnt\system32 by some
stranger's installer?). And I get everything to link against the C library
*I* prefer.

I feel that usually, people who try to actually *use* DLLs for third party
libraries on Windows are losing a fighting battle for no good reason.

And if, in your tree of dependencies, you have more than one C library, you
WILL run into problems other than Curl using the wrong malloc.

All of the above Windows venting aside, though, I do feel that curl_free
would be a nice thing to have :P Or, giving users the ability to tell Curl
which malloc/realloc/free they want it to use. I like the idea of memory
being freed by the same module of code that allocated it. I'll admit that
this is more an aesthetic preference than a useful technique.

- Andrew

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Received on 2002-09-20