In doing so, clean up the MD5 interface a little. Most existing users only care about the lower 8 bytes of an MD5, but for some users that care about the upper and lower, there wasn't a good interface. Furthermore, consumers of the MD5 checksum were required to handle endianness details on their own, so it seems reasonable to abstract this into a nicer interface that just gives you the right value.
- rL298322: Add a function to MD5 a file's contents.
It's pretty similar. The main difference is that SHA1 only gives you a sequence of bytes, and there is no option to return the result any other way without manual effort on the part of the user. I don't know if there is any good reason for this. It seems to be fairly common practice for consumers of MD5 checksums to truncate the hash and only use the first 8 bytes or the last 8 bytes. This seems much less common with SHA1 (as in, I don't know of any clients that do this, and I don't know if this affects the security of the hash in any way either).
If we can decide on a reasonable interface that allows both to be consistent, I'm happy to try to implement it (but hopefully orthogonally to this patch), keeping in mind that I'm not a hash expert, so I would not be the person to make any functional changes, but API changes are OK.