On Thu, 24 Jan 2008, Junio C Hamano wrote: > > I wonder if the issue Dave Miller addressed with > 69ae517541ed5ab7d4fdcd8f82a9b8bd949df347 (fast-import: fix > unalinged allocation and access) applies here. Good point, although we actually do things wrong for *another* reason. We currently force cache_entry to be 8-byte aligned regardless of what the actual "sizeof(ptr)" is, so we should assume that alignment: #define cache_entry_size(len) ((offsetof(struct cache_entry,name) + (len) + 8) & ~7) and if that isn't correct, we'd need to change this #define. So right now, the right thing to do is probably to make this alignment explicit: #define CE_ALIGN 8 and then use that both in the "cache_entry_size()" _and_ in the "estimate_cache_size()" calculations to make it obvious what the alignment is. And then we could actually make the alignment less on architectures that don't need that much (there may be architectures that need more, but I doubt it: we don't have any large fields in that structure, so the structure alignment really probably does max out at 8 in practice even if the C language theory doesn't give you any such guarantees). Side note: this is not likely to be a problem in _practice_. The on-disk representation is also aligned (also by 8), and while they can be *differently* aligned due to the relative alignment of the varying-length "name[]" field, and that can cause some padding to be needed, in practice it will never matter. The on-disk size also contains a header that we don't take into account, so it's already "over-estimated" to begin with for the in-memory representation. So "estimate_cache_size()" really does over-estimate its needs by a biggish amount, which is why it all works regardless, but better safe than sorry. Linus - 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
