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: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Sun, 11 Sep 2022 00:52:31 +0200 (CEST)

On Sun, 11 Sep 2022, Patrick Monnerat wrote:

>> 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.

Oh right. But also out of a coincidence we haven't yet had to check for a bit
over 31 bits - and when we go there we'll notice we need to bump the size of
that struct field (as we get compiler errors otherwise).

>> 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.

So far we can just limit new protocols for curl_off_t >= 64 bit systems. If
nobody shows up wanting those protocols on systems without 64 bit types, then
we don't have to address that issue.

> 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.

Yeah, I just don't think we need to go there yet.

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

Yeps.

-- 
  / daniel.haxx.se
  | Commercial curl support up to 24x7 is available!
  | Private help, bug fixes, support, ports, new features
  | https://curl.se/support.html
-- 
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html
Received on 2022-09-11