cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: Inconsistency in memory allocation

From: Philippe Lhoste <PhiLho_at_GMX.net>
Date: Fri, 20 Sep 2002 12:23:58 +0000 (UTC)

Daniel Stenberg <daniel_at_haxx.se> wrote in
news:Pine.GSO.4.44.0209201005130.16379-100000_at_pm1.contactor.se:

> On Fri, 20 Sep 2002, Andrew Francis wrote:
>
>> 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'.
>
> This makes my head hurt! ;-)

You are not alone :-)

>> 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.
>
> I think I'd prefer one of these approaches:
>
> 1. Offer a way to set which malloc/free functions libcurl should use.
> This
> will not work properly for underlying libraries that libcurl uses and
> that might allocate memory themselves. Then the app know which
> function to use for freeing data allocated by the lib.

These libraries should use similar approaches :-)

> 2. Don't ever send back any data that requires the received to free()
> it. In
> practise, that becomes:
> 2a) don't return "plain" allocated data (change the APIs of the
> functions
> that do this today).

A pain for most people using these APIs, obviously. And more annoying, as
you usually have to provide a buffer and its length, with risks of buffer
overloading, etc.

> 2b) offer a curl_free() (or similar) function
>
> I realize that option 2b gives the smallest possible impact, and won't
> even be required for users/platforms/compilers.

I still prefer this one :-)
Unix users (or other good platforms), or consistent Windows users can still
use the standard free() if they want, and quietly ignore the convenient
lua_free() ;-) Other users will have no longer such problems, or will be
happy to have symmetry between allocation of memory by cURL and freeing it.

Of course, since we have the source, we can easily add such a function, but
it won't work for third party DLLs and it is a pain to patch every upcpming
version.

Regards.

-- 
--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Received on 2002-09-20