On Sun, 6 Nov 2005, Bryan Henderson wrote:

>> That would mean using CURL_GLOBAL_NOTHING I guess?
>
> No, a user of this paradigm would never call curl_global_init(), and libcurl
> wouldn't care. He wouldn't call curl_easy_init(), so the implicit one would
> never happen.

Then the new paradigm would simply be (an implied) CURL_GLOBAL_NOTHING and a
curl_easy_init(). Wouldn't it?

>> I believe we might have a hard time to detect the lack of init for some
>> cases, so it might have to become an undefined behaviour for that
>> situation.
>
> I see no reason to try to detect lack of init. The user is responsible for
> doing the necessary global init. If he doesn't, and tells us that he did,
> that's the same as when he hands us something he says is a CURL handle, but
> is really uninitialized memory. (I.e. undefined behavior).

I agree, but your suggestion said that we should return an error back for this
case and I was just saying it might be hard. No big deal really.

>> The big problem with this approach however, is that we have a whole bunch
>> of functions in libcurl that don't take any easy or multi handle as input
>
> I will take a careful look at all the functions. The only ones that matter
> are ones that access sockets, use idna, or allocate memory.

... and those that *might* do it in the future.

> In any case, I am reluctant to make any change that makes old programs not
> compile with the new libcurl. I would rather add new functions and
> deprecate the old ones.

A very sensible approach I'd say.

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