cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: giva: curl/lib getinfo.c,1.39,1.40

From: Daniel Stenberg <daniel-curl_at_haxx.se>
Date: Mon, 13 Dec 2004 23:17:03 +0100 (CET)

On Mon, 13 Dec 2004, Gisle Vanem wrote:

>> As you can see now in the autobuilds, this breaks the build on all systems
>> that doesn't have engine support enabled... (since engine_list is only
>> present on those that have engine support)
>
> Obs, then '*param_slistp' should be NULL.

Only if you move it outside the #if -condition in lib/urldata.h!

>> I would prefer the returned list to be the responsibility of the app to
>> free with curl_slist_free_all() and libcurl would thus not need to remember
>> this list.
>
> I though the general idea was; if memory is allocated in libcurl, it should
> free the memory too.

Nah, there are in fact several functions that return memory that must be
curl_free()ed. The general idea I try to follow is that if it makes sense to
let the app have the responsibility and to disconnect the allocation from the
easy handle, then do so. I think this is such a case.

Also, I think further on my upcoming list-cookies case and there we'll
definetely want to let the app free the list. I guess it makes sense to have
all "list-types" require the same action by the app.

> Re. the docs; I'm no groff guru, but have updated curl_easy_getinfo.3 and
> curl.1.

It isn't that hard to just follow the already used formatting. The hard parts
are when you want to do something no other parts of the docs is already doing,
since then you actually have to figure out what weird syntax that's needed...
:-)

-- 
      Daniel Stenberg -- http://curl.haxx.se -- http://daniel.haxx.se
       Dedicated custom curl help for hire: http://haxx.se/curl.html
Received on 2004-12-13