On Fri, 13 Oct 2006, Mohun Biswas wrote:

>> Let's say we'd add a curl_easy_getopt() function that can return (some of
>> the) options you can set to the easy handle. How would the application know
>> what data to request from libcurl in order to free it after an operation?
>
> I (truly, sincerely, and respectfully) do not understand the counter
> argument here.

That was not meant as a counter argument. I just meant to say that adding a
curl_easy_getopt() is not the whole solution to the problem of "knowing what
to free after a libcurl request" for many applications. And subsequenctly,
isn't it just a half-baked solution to just add the curl_easy_getopt() ?

Like in the case where you use libcurl to add a few headers, possibly POST
data, a URL and some more.

When the transfer is completed there's time to free up the resources
associated with this request. What resources?

Yes, in a simple application you always know that you allocated the URL so you
could unconditionally curl_easy_getopt(URL) and free it. But as has been seen
so many times over, people write more complicated libcurl-using apps than so,
and therefore will the sitaution very likely end up like: time to free some
resources, and depending on what resources we allocated before we need to free
exactly those.

For the app's cleanup-function to know what resources to free in this
scenario, it would need to do bookkeeping and ask for and free exactly those
pointers it previously allocated. This extra bookkeeping, would need to be
passed around by the application and IF that extra bookkeeping is passed
around anyway, what's the big difference to it if it would also keep the
actual pointers of the memory allocations?

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html