Re: [PATCH 2/2] Support sizes >=2G in various config options accepting 'g' sizes.
From: Nix <hidden>
Date: 2016-06-15 22:51:59
On 6 Sep 2011, Clemens Buchacher uttered the following:
On Mon, Sep 05, 2011 at 02:56:10PM +0100, Nix wrote:quoted
Well, we're parsing longs, not ints. If sizeof(long)>sizeof(int), or we have long long and sizeof(long long)>sizeof(int), then we can always detect overflows when saving into the appropriate type: but if we don't have long long, or if we have neither strto(u)ll() nor strto[ui]max(), we could only detect overflow by looking at the raw text string and checking it by hand to see if it would fit. I judged this pointless extra complexity for a very rare edge case (machines with neither strot(u)ll() nor strto[ui]max() are generally quite old and people aren't going to be specifying sizes in gigabytes on such machines anyway.)Is this also true for Windows and other platforms?
There, uintmax_t is 'long long' and is longer than 'long', let alone 'int', so this holds there too, or should.
And I don't think it's about whether or not people are likely to specify sizes in gigabytes on old machines. People are bound to blindly copy configuration files from one machine to another. In any case, my expectation would be for the configuration options to do what I tell them, or error out if they do not make sense.
Yeah, and we do that whenever practically possible: but fixing this for the case that int/long is the largest available type (which among other things implies that we're not using GCC or any other C99 compiler or any of the myriad C89 compilers that implmented 'long long') amounts to writing our own strtol() specifically for this one case, to see if the parsed number is too long. And that is probably a maintenance burden too far. The failure mode if you put a huge number in on such a platform is better than it used to be, too, especially for core.bigfilethreshold. We used to get a negative number that was latched to zero, which then disabled compression entirely (I had an 83Mb pack turn itself into an 837Mb one when that happened). Now we get a number that, while positive, is less positive than we expect, but still likely up in the hundreds of millions. -- NULL && (void)