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: Above and beyond 32 protocols

From: Patrick Monnerat via curl-library <>
Date: Mon, 13 Sep 2021 17:09:47 +0200

On 9/13/21 1:01 PM, Daniel Stenberg via curl-library wrote:
> I think the libcurl architecure is pretty well designed by now to
> handle different and more protocols. There is however at least one
> bottle neck that we need to address: the CURLPROTO_ defines.
I was thinking exactly that when developing ManageSieve.
> # Ways out of this dilemma?
> I can think of two ways. Neither is without a cost.
> A) If we drop the < 64 bit requirement (1), we can introduce
> CURLOPT_PROTOCOLS_LARGE etc that use a (guaranteed) 64 bit type and we
> double room for protocols, which should be enough for the forseeable
> future.
> B) If we maintain the < 64 bit requirement (1), we would have to do
> something like introducing a *second* protocol option for the next set
> of protocols. It would be error-prone and cumbersome for users (it
> will appear semi-random as to which protocols that appear in which
> bitmask etc) and also inconvenient to handle internally. Perpaps one
> of the bits in the first bitmask should then signal that there are
> bits set in the second one. Or perhaps that's not necessary.
I can imagine an other solution. I'm afraid it breaks the ABI:

C) Spare some bits (at least 5: I did not check) by not defining the TLS
versions of CURLPROTO_* and have a global CURLPROTO_TLS for all of them.
Maybe together with macros like #define CURL_HAS_HTTPS(protobits)


Received on 2021-09-13