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: Sun, 11 Sep 2022 00:39:16 +0200

On 9/10/22 23:08, Daniel Stenberg wrote:
> On Sat, 10 Sep 2022, Patrick Monnerat via curl-library wrote:
>> In the meantime, CURLOPT_PROTOCOLS_STR has been added for caller's
>> use, but this only translates to bits and the internal problem has
>> not been resolved yet.
> It depends on what you mean. It is solved for all systems that have a
> 64 bit size variable type.
I don't think it is: I did not check everywhere, but at least
Curl_handler protocol and family fields are still unsigned ints.

> I am not sure if there actually still are systems in use that don't.

That's why I was suggesting to constrain curl_off_t >= 64 bit.

>> Do we have now an idea how we want to extend this internally ?
> You mean for 32 bit systems without larger types or for when the 64
> bits have filled up?

The former is the most urgent if we still want to support such systems.
I don't know if I'll still be here when 64bit will be exhausted,
although it may come faster than expected :-)

I'm in favor of using a protocol number enum for single protocol values
and an FD_SET-like strategy for allowed_protocols and redir_protocols.

Family handling should also be adjusted (using single proto number
everywhere and drop PROTO_FAMILY_* symbols).

BTW: we'll soon have the same problem with feature bits.


Received on 2022-09-11