Re: [PATCH 2/2] teach git-config to output large integers

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Aug 21, 2013, 04:38 UTC
Message-ID: <20130821043841.GA2802@elie.Belkin>
In-Reply-To: <20130821030036.GD25296@sigill.intra.peff.net>

Jeff King wrote:

Show 8 quoted lines

> 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 internally, so 32-bit systems
> with largefile support do the sane thing. But now you have no way of
> emulating the way that git parses stuff internally.

Let's take a step back for a moment. What problem is this patch solving?

>From the motivating example, I thought it was

	When reading or writing an integer config item, git sometimes
	encounters integer overflow and doesn't know how to deal with it.
	Worse, this means that some meaningful values are unrepresentable
	in config files.  Fix it in two steps:

	 1. Catch overflow, and error out instead of pretending to be
	    able to handle it.

	 2. Provide at least an option to use a wider integer type and
	    handle larger meaningful values.

	This involves a new option --size instead of making --int use
	intmax_t for the following compatibility reason: ...

For example, the compatibility reason could be that some scripts calling "git config" were not able to handle large integers and that we do not want to expose them to unexpectedly large values.

But that reason doesn't sound realistic to me. So what is the actual reason not to always use a wider range?

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 even better, computing the right size and printing it, is an acceptable behavior, and this test checks for those."

Hoping that clarifies, Jonathan