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: Patrick Monnerat via curl-library <curl-library_at_lists.haxx.se>
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.
Patrick
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.
Patrick
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2022-09-11