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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
