Hi, On Wed, 9 May 2007, J. Bruce Fields wrote: > On Wed, May 09, 2007 at 06:25:01PM +0200, Johannes Schindelin wrote: > > None. I only suspected them to be carried out in byte order. From what I > > know, there are some shifts involved, which might or might not be helped > > by 32-bit arithmetic. > > > > I did not really look into it. > > > > From my prior debugging experiences on Intel, though, I automatically > > looked for the least significant bytes at the beginning of those "sha1" > > variables, and came up empty. > > So, I'm confused about what you actually mean by "big endian" here. I > originally assumed that you meant that SHA1's are defined as bit arrays, > and that the first bit of the SHA1 is in the high-order bit of the first > byte. But if you just meant that the first byte of the SHA1 is stored > in the first byte of the array... that kind of goes without saying, > doesn't it? Hm. Let me explain it in this way: If you parse a number, passed to a program, with strtol(argv[1], NULL, 0) you would expect something like this on an Intel processor: Input 0x1234 -> memory 0x34 0x12 0x00 0x00. On a big endian machine, you'd expect 0x00 0x00 0x12 0x34. That is what endianness means. If you tell Git that it should look for commit e83c6516..., it will store the sha1 as 0xe8 0x3c 0x65 0x16 ... in memory, no matter which endianness the processor has. Which was positively confusing for me, since I automatically searched for the sequence 0x90 0xf2 0x4a 0x60 ... (which is the tail of that hash). But if all this sounds too confusing, I agree to delete the "(big-endian)". Ciao, Dscho - 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
