Re: Pack files, standards compliance, and efficiency

Duy Nguyen [off-list ref] writes:

I'm more concerned about breaking object_id abstraction than C
standard. Let's think a bit about future. I suppose we need to support
both sha-1 and sha-512, at least at the source code level. That might
make casting tricky.

If we support both, the code that writes today's objects should be
aware that they are writing today's uchar[20] (or char[40]) object
names, no?  I do not view crusty's series as a step to change the
hash, but more about identifying the arrays used as object names and
differentiating from other char and uchar arrays, so that it will
help us to identify the codepaths that needs to be updated when we
change the hash function.  Ideally, the result of applying his
series should produce the binaries identical to today's code that
uses uchar[20] as object names.

I do not see any "breaking object-id abstraction" involved when
isolated low-level code that writes things to and reads things from
the disk or core knew that the hash we happen to use is uchar[20],
and it is perfectly fine if casting lets us safely take advantage of
that knowledge.  It becomes a problem when we peek into the struct
object_id to find address of sha1[20] and then start passing that
low level address around widely, but I do not think this thread of
discussion has risks to go into that direction.