Junio C Hamano <junkio@xxxxxxx> wrote: > Shawn Pearce <spearce@xxxxxxxxxxx> writes: > > > Using a 28 byte index entry instead of a 32 byte index entry means > > the Mozilla historical pack index will only be 52.4 MiB rather than > > the slightly larger 59.9 MiB. > > Yup, that was one consideration. One small worry is we will be > placing u64 at 4-byte alignment by using 28-byte entries but I > think that is Ok. On some systems (SPARC?) that's definately an issue. Other systems (x86) obviously don't have that problem. If you code the decode function as treating that 64 bit value as two 32 bit values in network byte order and combine them together after ntohl() then this shouldn't be a problem. Though big-endian systems which can take a u64 on a 4-byte alignment just fine would pay a small performance penalty that they don't need to pay. -- Shawn. -- VGER BF report: S 0.998672 - 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