On Thu, Jul 14, 2016 at 01:22:01PM -0700, Junio C Hamano wrote: > > Also, shouldn't it be checking against 0xFFFFFFFF? > > Correct. Somehow I thought I was checking with LONG_MAX. Will correct. > > > An easier check would be "sizeof()", but I guess we can't use that in a > > preprocessor directive. > > Yes, I tried it and failed ;-)
I also found it funny that you used "==" instead "<=", but I cannot really think of a case where it would matter. If it is "<= 0xFFFFFFFF", that basically covers 16-bit platforms. I really hope nobody is trying to run git on such a platform. Doing "< 0xFFFFFFFFFFFFFFFF" to check for "less than 64-bit" would make more sense, but would probably choke on a 32-bit preprocessor. So that everybody is either 32- or 64-bit these days, I think it doesn't matter in practice. > >> -test_expect_success TAR_HUGE 'system tar can read our huge size' ' > >> +test_expect_success TAR_HUGE,64BIT 'system tar can read our huge size' ' > > > > The 64BIT prereq is really "unsigned long is 64-bit". I wonder if we > > should call it UL64 or something like that to make it more clear. > > > > That makes it unnecessarily tied-in with the implementation, but it does > > make it more clear what we care about; the distinction matters for > > things like LP64 vs LLP64. > > I do not think any platform is weird enough to have different sizes > for long and ulong, so I am not sure you need UL64. > > But pointer size can legitimately be different, so it has a value to > differentiate between LP64 and LLP64, if we start doing things like > "does this platform have large virtual address space?" > > LONG_IS_64BIT perhaps to be more readable? Yeah, that is what I was trying to get at, but you stated it much more clearly. LONG_IS_64BIT is good. I wonder if the "git version --build-options" should be "sizeof-long", too. It's shorter, and indicates our assumption that we are talking about all longs, not just unsigned ones. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
