Duy Nguyen <[email protected]> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
