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 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html