This would be nice, because then if it failed, you could get error
information out. One problem I have had is that if I've got a bug where
I've leaked sockets, and curl_easy_init starts failing, I can't get a
reasonable error code out without hacking up the code....

-----Original Message-----
From: curl-library-bounces_at_cool.haxx.se
[mailto:curl-library-bounces_at_cool.haxx.se] On Behalf Of Daniel Stenberg
Sent: Friday, March 04, 2005 3:10 PM
To: libcurl development
Subject: Re: curl_easy_init_options (Was: Re: ARES configuration)

On Fri, 4 Mar 2005, codemastr wrote:

> Microsoft (and I'm sure others) have a pretty simple solution for this
that
> they use in many of the WinAPI calls. Basically, you have the user
specify
> the size of the structure:
>
> struct curl_options copt;
>
> copt.struct_size = sizeof(struct curl_options);

Yes, that's a neat way to deal with it. Another way that I've introduced
in
the curl_version_info() is that the first struct member is a 'version'
info
and apps always set it to "CURLVERSION_NOW". The header is then
responsible to
have it increased when the struct changes.

In this particular case, another option to solve this would be to delay
the
creation of the ares "channel" to after the curl handle is made and then
allow
ordinary curl_easy_setopt() calls to change these ares things. Then we
could
even close and recreate the ares channel if options are changed "mid
stream".

Hm, thinking more about it, I believe I begin to favour this latter
way...

-- 
      Daniel Stenberg -- http://curl.haxx.se -- http://daniel.haxx.se
       Dedicated custom curl help for hire: http://haxx.se/curl.html