On Sun, 26 May 2002, Vladimir Tsichevski wrote:

> >> Had curl_easy_setopt() copy the strings with strdup() would solve that
> >> problem.
> >
> >Is this really a problem?
>
> Yes, it is. I do not use libcurl directly, but from within Scheme
> language environment. All the Scheme memory is managed by a garbage
> collector. Usually the Scheme application writer never bothers about the
> memory issues at all. So I have the only two solutions, I do not know
> which is worse:
>
> 1. Just strdup() the strings and agree with that explicit memory leaks.
> Very unpleasant.

This seems like the worse alternative to me.

> 2. Completely redesign my Scheme-to-CURL bindings by wrapping the pointers
> to a `curl' structures by a new structure keepeng track of all the strings
> bound, and explicitly free that data every time the curl_easy_cleanup() is
> called. Possible, but too complex solution comparing

I don't mean to be rude here, but the docs have mentioned this for a long
time so you made your binding code wrong in the first place.

Yes, it would mean that you would need to allocate a separate struct that
would keep the strdup()ed pointers and the CURL handle until they are no
longer used. I can't see how that is very complex.

> >I made it this way deliberately from the beginning, as it makes libcurl do
> >less malloc()/free() operations.
>
> You still have track whether the data is malloc()ed to enable
> curl_easy_duphandle().

No I don't. *_duphandle() does not completely strdup() all char * data. It
clones a few strings that it needs to, the rest it'll keep referencing to.
Like extra HTTP-headers, custom FTP commands, custom requests, SSL ciphers,
kerberos4 security level, user and password strings... and a few more.

> Making it alwais malloc()ed just reduces that code.

For those strings that it strdup()s, yes.

> Besides a few extra malloc() calls do not make programs dealing with
> network transfers notably slower.

Very true. It isn't about speed, it is about wasted resources. Yes, you can
argue that strdup() a couple of hundred extra bytes may not be that bad but
that is still the reason for this design decision. Actually, it has been like
this for a long time and you're the first one to bring this subject up!

> > In many cases they won't be needed, since
> > the application will have the data kept around anyway.
>
> Why should it?

Because it uses libcurl synchronously, so it won't have any chance to remove
the resources until libcurl is done using them.

> It complicates the program and makes it more error prone.

I beg to differ.

-- 
    Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm