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