I figure that examples/xmlstream.c should be updated too as it unsets this flag.

On 27 November 2017 at 17:38, Daniel Stenberg <daniel_at_haxx.se> wrote:
> On Fri, 17 Nov 2017, Daniel Stenberg wrote:
>
>> Nowadays though. Is anything or anyone using this feature (disabling
>> CURL_GLOBAL_SSL) for a good purpose and if so, can you please elaborate on
>> why and how? (I don't think "I won't use any TLS protocols" is a good
>> reason.)
>
>
> Update:
>
> Me and Ray have discussed this topic back and forth extensively on github in
> several PRs. We still disagree on the best approach to proceed from here,
> but as we have a release coming in less than 48 hours I had to make a
> decision so that we at least fix the current bugs at hand.
>
> This morning I landed PR #2107 as commit d661b0afb. It makes libcurl ignore
> CURL_GLOBAL_SSL. It becomes a no-op. libcurl will now always initialize the
> TLS library stuff and all the relevant TLS internals if built with TLS
> support.
>
> The risk: that there's actually a legitimate user somewhere out there who
> disables the libcurl SSL init for a good reason and that now will suffer
> from some obscure problems. I do however think that if there is such a user,
> they should get problems early and immediately. I estimate the risk for this
> to be very small.
>
> The backup approach: should the risk turn out real and my estimate be crap
> (it has happened before! :-O), the plan is to then backpedal and go with
> #2112 [*] instead.
>
> [*] = https://github.com/curl/curl/pull/2112>
>
> --
>
> / daniel.haxx.se
> -------------------------------------------------------------------
> Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library> Etiquette: https://curl.haxx.se/mail/etiquette.html
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2017-12-01