curl / Mailing Lists / curl-library / Single Mail


Re: Curl_resolv_timeout SEGV in MT

From: Pawel Veselov <>
Date: Fri, 27 Jan 2017 11:30:29 -0800

On Thu, Jan 26, 2017 at 10:56 PM, Daniel Stenberg <> wrote:
> On Thu, 26 Jan 2017, Pawel Veselov wrote:
>>> Agree. Then "synchronous" or "blocking".
>> I also think it may be more important to add "change with" before the
>> alternative options. It's crispy clear for some other cases, just not for
>> this one.
> But it would break the symmetry with all the other options. They all show
> the current situation and within paretheses options that can change it.
> What if we instead made it appear like this, with the left "label" being
> changed to "async resolver"?
> Async resolver: no (--enable-ares / --enable-threaded-resolver)

Well, I was suggesting to change that for all configuration status lines.

I was then thinking, well, then may be there should be a message above saying
- "values in parenthesis indicate which configure options would alter the
determined configuration". Well, may be in capital letters.

But this honestly made me think that hey, I'm new to libcurl. Once I made
this mistake, it's unlikely I make it again for now. Would I have read that
text? I'm not sure. If two years pass and I need to play around with libcurl
again, would I remember this, and would I read everything thoroughly then?
I'm not sure.

In other words, in my opinion, it's often hard to prevent users from shooting
themselves in the foot with a new gun. And one can only put that much effort
into preventing that.
Received on 2017-01-27