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