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
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
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.
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.htmlReceived on 2022-09-11