Hi Daniel, On Fri, 17 Nov 2017, Daniel Stenberg wrote:
> A long time ago we added the ability to ask libcurl to *not* initialize the > TLS library (which iirc only was OpenSSL at the time) if you removed the > CURL_GLOBAL_SSL bit from the curl_global_init() call. > > The idea was that if you already initialized OpenSSL in your application you > might want to avoid that libcurl does it again. I believe there was once a > problem in OpenSSL with doing multiple initializations. I don't think it ever > made much sense for any other backend, but the option remained and is > documented and everything. The default action is of course that libcurl inits > the TLS stuff. > > 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.) Not using it in Git, either. > When we introduced multissl support in libcurl, the application can ask > libcurl in run-time to pick a TLS backend and that makes this case even > weirder. So an application disabling the CURL_GLOBAL_SSL bit in a multissl > case would also init TLS differently based on the chosen backend libcurl will > end up using. Even more unlikely to happen in the real world. One stupid workaround would of course be to replace the `(size_t)-1` in `Curl_ssl_multi` by something stupidly large, such as 4096 (with the idea that no TLS backend-specific data requires that much space, and 4096 being naturally aligned to even 8-byte boundaries). That stupid workaround would allow us to not rush the decision on CURL_GLOBAL_SSL... Ciao, Dscho ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
