curl / Mailing Lists / curl-library / Single Mail
Buy commercial curl support from WolfSSL. We help you work out your issues, debug your libcurl applications, use the API, port to new platforms, add new features and more. With a team lead by the curl founder himself.

Re: curl_version_info() thread-safety

From: Patrick Monnerat via curl-library <>
Date: Sun, 25 Sep 2022 13:01:17 +0200

On 9/25/22 10:30, Daniel Stenberg wrote:
> On Sun, 25 Sep 2022, Patrick Monnerat wrote:
>> main()
>> {
>>   const curl_version_info_data *vid;
>>   vid = curl_version_info(CURLVERSION_NOW);
>>   printf("%08X\n", vid->features);
>>   curl_global_sslset(CURLSSLBACKEND_OPENSSL, NULL, NULL);
>>   curl_version_info(CURLVERSION_NOW);
>>   printf("%08X\n", vid->features);
>> }
>> Result (with a MultiSSL library):
>> 75DFE7DD
>> 75FFE7DD
> Right, but I would argue this is not using the API as documented and
> intended. The global init call should be called before
> curl_version_info() if you want it to return a "stable" value.
This can introduce a chicken-and-egg-like problem:

- curl_version_info() has to be called to know multiSSL is featured

- curl_global_sslset() must be called before curl_global_init()

- from your statement above, curl_version_info() has to be called again
after curl_global_init()

I don't see any incompatibility with the documentation. The sequence
above probably won't hurt most programs, but is not threadsafe.

The problem is: HTTPS-proxy is not really a libcurl feature with
multiSSL, rather an SSL backend feature. Curl features were not
initially designed to be dynamic but more of a curl initial
configuration state.

IMO, features can be detemined at run-time (like it is done for IDN),
but the result should not change over time.

I see only 2 solutions to this:

1) Consider multiSSL as a backend on its own that do not support
HTTPS-proxy. Even after setting the real backend.

2) Document curl_version_info() as not threadsafe until
curl_global_init() is called.

Received on 2022-09-25