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: Ray Satiro via curl-library <>
Date: Tue, 28 Sep 2021 17:49:49 -0400

On 9/13/2021 7:01 AM, Daniel Stenberg via curl-library wrote:
> 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 like CURLOPT_PROTOCOLS_LARGE and I think that we could continue to
support systems that do not have a 64-bit type (like what?) by not
defining those proto masks for them. I think a bigger problem would be
users that continue to use CURLOPT_PROTOCOLS and the like but pass those
options extended protocols, effectively passing a curl_off_t to an
option that expects a long. We could have a signal bit like a trouble
bit in every extended protocol and then check what is passed in
curlopt_protocols for the trouble bit and refuse to work in such a case.
Like this

#define CURLPROTO_DONT_USE (1<<31)

CURLPROTO_ALL could still technically enable everything

and in CURLOPT_PROTOCOLS setopt:

long allowed_protocols = va_arg(param, long);

if((allowed_protocols&CURLPROTO_EXTENDED_FLAG) && allowed_protocols !=
  /* problem */

Received on 2021-09-28