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 02:22:49 +0200
On 9/11/22 00:52, Daniel Stenberg wrote:
> 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).
>
We already are there: the ManageSieve protocol is still pending and I'm
maintaining it for 1 year now and will do as long as not rejected (BTW:
the "needs vote" flag is just a fiasco: no directive for it, no appeal
for, etc. Better have a code bucket! I feel it like an unassumed
rejection and I'm sure the lack of advertising/links/doc of the "needs
vote" feature is responsible for that rather than the PR itself, as
other flagged PRs do not have votes either). The PR stayed fully
operational until the proto bits exhausted.
Even without it, let's assume we'll have a PR for rsync tomorrow: the
current proto limitation is a barrier for the PR developer, whoever he
is. IMO we must be ready for that and the next protocol PR should not
worry about it and have the same questions we deal with here.
>>> 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.
Yet it would even break the 64-bit limitation and allow a 32-bit only
system to work!
Patrick
Date: Sun, 11 Sep 2022 02:22:49 +0200
On 9/11/22 00:52, Daniel Stenberg wrote:
> 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).
>
We already are there: the ManageSieve protocol is still pending and I'm
maintaining it for 1 year now and will do as long as not rejected (BTW:
the "needs vote" flag is just a fiasco: no directive for it, no appeal
for, etc. Better have a code bucket! I feel it like an unassumed
rejection and I'm sure the lack of advertising/links/doc of the "needs
vote" feature is responsible for that rather than the PR itself, as
other flagged PRs do not have votes either). The PR stayed fully
operational until the proto bits exhausted.
Even without it, let's assume we'll have a PR for rsync tomorrow: the
current proto limitation is a barrier for the PR developer, whoever he
is. IMO we must be ready for that and the next protocol PR should not
worry about it and have the same questions we deal with here.
>>> 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.
Yet it would even break the 64-bit limitation and allow a 32-bit only
system to work!
Patrick
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2022-09-11