Sun He <sunheeh...@gmail.com> writes: > hashcpy() can keep the abstraction of "object name" behind it.
Do we really want to change the phrasing you took the above from to say "*can* keep"? Providing the "object name" abstraction is the whole point of the function, so of course it can keep it, but that goes without saying---it was the sole reason why it was invented in the first place. > Use it instead of memcpy() with hard-coded 20-byte length when > moving object names between pieces of memory. > We can benefit from it, when we switch to another hash algorithm, > eg. MD5, by just fixing the hashcpy(). "fix" can be used in two scenarios, I think. Something is broken and you fix it, or something keeps changing and you force it not to change. I do not think either applies to hashcpy(). Perhaps "updating", if we really wanted to say it, but because this change is not about preparing us to any planned switch of hash function, I'd suggest dropping those two lines starting from "We can benefit from...". > Leave ppc/sha1.c as it is, because the function is about the > SHA-1 hash algorithm whose output is and will always be 20-byte. Correct. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
