Daniel Stenberg wrote:
> I'm not convinced that is a compelling argument. You still need to know
> exactly which of these values to extract and how to free each one of
> them, which thus forces you to pass logic around for that and if you do
> that, having the actual pointers stored too is hardly much extra work.

This part doesn't make sense to me. Quite possibly other people program
libcurl differently but at least in my case, and I'd imagine in many
others, these things are a matter of policy. In the original use case, I
allocate an error buffer for every easy handle so there's no trick to
knowing that it must be freed subsequently. There's no need to "pass
logic around" - merely to have access to the pointer at cleanup time.

I'm not necessarily arguing for a curl_easy_getopt - my own view is more
limited. It just seems inelegant that I have to invent my own struct -
or list of structs or struct of lists or whatever, because I use
CURLOPT_PRIVATE for other things too - simply to pass along *copies* of
pointers which the libcurl API already knows about and expects me to
free. It just seems cleaner to ask it "what was that error buffer's
address again?"

An alternate solution might be found by comparison with curl_formadd
which gives the choice of PTR (you free it) or COPY (we free it for you)
pointers. But that's another dimension of complexity.

Or one could imagine a way of registering pointers to be freed at
cleanup time:

        char *errbuf = calloc(CURL_ERROR_SIZE, 1);
        curl_easy_setopt(curl, CURLOPT_ERRORBUFFER, errbuf);
        curl_easy_setopt(curl, CURLOPT_FREE_AT_CLEANUP, errbuf);

which might have the smallest code and doc impact.

> Of course the discussion is what features that would fit this
> description and what features that don't.
>
> In general, when I'm leaning towards a 'no' for including something I
> want to see what others have to say about the suggestion and if then
> there's very little support or talks about it, I consider that in favour
> of my way...
>
> So, is there anyone else around with opinions in this matter? Be it in
> favour or against, I'm interested.

Likewise.

MB
Received on 2006-09-02