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 11:13:07 +0200 (CEST)
On Sun, 11 Sep 2022, Patrick Monnerat wrote:
>> out of a coincidence we haven't yet had to check for a bit over 31 bits
> 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
I was talking about code in master, but sure for new ones we will reach it.
I think we should just use a larger type for protocols and family then, and I
think new protocols should require curl_off_t >= 64 bits to be enabled.
> (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.
Feel free to propose better approaches or ways to improve it. Without the
votes, I feel the decision too often lands on me and I don't know and I am by
nature rather conservative and resist lots of new things into curl and I
rather not close down fine PRs if there "people" think we should support them.
> 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.
True.
> 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.
...
> it would even break the 64-bit limitation and allow a 32-bit only system to
> work!
But be more code and more complicated to use and understand than just using a
larger type. So the question is if we need the more complexity or can get away
with the simpler solution for another twenty years or so.
Date: Sun, 11 Sep 2022 11:13:07 +0200 (CEST)
On Sun, 11 Sep 2022, Patrick Monnerat wrote:
>> out of a coincidence we haven't yet had to check for a bit over 31 bits
> 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
I was talking about code in master, but sure for new ones we will reach it.
I think we should just use a larger type for protocols and family then, and I
think new protocols should require curl_off_t >= 64 bits to be enabled.
> (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.
Feel free to propose better approaches or ways to improve it. Without the
votes, I feel the decision too often lands on me and I don't know and I am by
nature rather conservative and resist lots of new things into curl and I
rather not close down fine PRs if there "people" think we should support them.
> 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.
True.
> 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.
...
> it would even break the 64-bit limitation and allow a 32-bit only system to
> work!
But be more code and more complicated to use and understand than just using a
larger type. So the question is if we need the more complexity or can get away
with the simpler solution for another twenty years or so.
-- / 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