Re: [PATCH 2/2] Support sizes >=2G in various config options accepting 'g' sizes.

[Nix <nix@esperi.org.uk>]

On 6 Sep 2011, Clemens Buchacher uttered the following:

> On Mon, Sep 05, 2011 at 02:56:10PM +0100, Nix wrote:
>> 
>> 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)