Jeff King wrote:
> On Tue, Aug 20, 2013 at 09:38:41PM -0700, Jonathan Nieder wrote:
>> That is what I was trying to get at in discussing the test. It is not
>> "We would like --int to reject values higher than this, but some
>> platforms do not allow us to", but "Either rejecting this value, or
>
On Tue, Aug 20, 2013 at 09:38:41PM -0700, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > I almost sent it as "--size" with unsigned long internally. But try
> > writing the documentation for it. You want to say something like "it's
> > big enough to handle file sizes". Except that on 32-bit, it'
Jeff King wrote:
> I almost sent it as "--size" with unsigned long internally. But try
> writing the documentation for it. You want to say something like "it's
> big enough to handle file sizes". Except that on 32-bit, it's _not_.
> It's only 4G.
>
> You really want something that uses off_t inter
On Tue, Aug 20, 2013 at 03:57:45PM -0700, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > I kind of hate the name "--ulong". I wanted to call it "--size" or
> > something and abstract away the actual platform representation, and just
> > make it "big enough for file sizes".
>
> Yes, something li
Jeff King wrote:
> I kind of hate the name "--ulong". I wanted to call it "--size" or
> something and abstract away the actual platform representation, and just
> make it "big enough for file sizes".
Yes, something like --size would be more pleasant.
It could still use unsigned long internally.
Internally we use "unsigned long" to represent large config
values like packed window memory sizes, packfile size
limits, etc. On 32-bit systems, this limits these config
options to 4G (and we detect and complain about overflow).
On 64-bit systems, they get the full 64-bit range.
However, there i
6 matches
Mail list logo
