Dan Fandrich wrote:
> On Mon, Aug 28, 2006 at 08:04:28PM -0400, Mohun Biswas wrote:
>>> If there's a way to solve this without CURLINFO_ERRORBUFFER, please tell
>>> me.
>> What's the story with this? Thumbs up, thumbs down, or what? I need to
>> know whether to write my code to assume its existence or not.
>
> Can't you store the errorbuffer pointer in a private struct and link it to
> the handle with CURLOPT_PRIVATE instead?

Well, yes, but let me recast the issue. On further thought, this is the
sort of thing that belongs in a curl_easy_getopt() function, not
curl_easy_getinfo. So I did a little web searching and found that it's
come up before (cf <http://curl.haxx.se/mail/lib-2005-09/0246.html>). In
that thread, Daniel was reluctant to allow curl_easy_getopt in without a
compelling argument for it. It seems to me that the requirement to free
our own data is the compelling argument, because there are a number of
values (URLs, error buffers, slists, etc) which have to be set into the
easy handle with curl_easy_setopt and which we (API users) have the
responsibility of freeing later, and quite possibly in a different stack
frame.

So yes, we could invent our own structures containing lists of pointers
to free and pass those around using CURLOPT_PRIVATE. But to my mind,
CURLOPT_PRIVATE is an escape hatch analogous to eval in Perl or being
able to insert assembler code into C code - it's good to have the option
for special situations but if something is being done predictably and
repeatedly, it's better to add true support for it.

And finally, I find the argument made in the referenced thread
persuasive too. It is that a curl easy handle is basically an object
with a bunch of attributes. The great majority of the SW world has come
to agree that the setter/getter paradigm is valuable, so what's the
argument for libcurl offering setters but no equivalent getters? We can
always keep track of the data we set into the object but that basically
means two copies with all the opportunities for skew and added
complexity that entails.

Thanks,
MB
Received on 2006-08-29