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! ;-)

> 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.

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).
   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'm very interested in peoples opinions on this.

-- 
 Daniel Stenberg -- curl related mails on curl related mailing lists please
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf