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

From: Nix <nix@esperi.org.uk>
Date: Sep 4, 2011, 23:49 UTC
Message-ID: <87fwkbool2.fsf@spindle.srvr.nix>
In-Reply-To: <CA+Jd1rGjkiabc9VePMmY6+8vhiGr7MgdwSNFToMsC0oBFNL6+g@mail.gmail.com>

On 4 Sep 2011, Clemens Buchacher uttered the following:

Show 7 quoted lines

> On Sep 4, 2011 11:25 PM, "Nix" <nix@esperi.org.uk> wrote:
>>
>> I haven't tried to fix things on 32-bit platforms, because there
>> is no real point setting any values to >2G on such platforms
>> anyway, and minimal likelihood that anyone would try.
>
> I absolutely would not count on that.

I was just operating under the assumption that since nobody had spotted this in years... OK, OK, perhaps that's a bad idea.

Show 7 quoted lines

>> The only
>> real fix possible would be a diagnostic warning of an attempt to
>> set a ridiculously high value, unless we want to use 'long long'
>> everywhere, which I doubt.
>
> I think an error message would be appropriate. Best if we die immediately
> when that option is read.

Yeah. None of the affected options impact the pack format (as, say, pack.depth does) so there is no danger of 32-bit users being barred from reading packs created by 64-bit users with high values for these settings.

(We have no way of guaranteeing that we can even report this, though:
 we can only even read in a >32-bit number if NO_STRTOULL is not
 defined. Still, I agree that if we *can* report this, we should.)

>                           We wouldn't want e.g. clone to die when it just
> finished downloading. And some documentation for those limits would be
> great, while you're at it. :-)

I'll send a new patch tomorrow.

... hm, pack.packsizelimit is also affected. I'll plug that too.

-- 
NULL && (void)