Hi Kevin,
* The implementation should be endian invariant to make cross platform digest checks feasible.
The message digest algorithms cannot know the layout of your data, i.e. is the data you're passing in a bunch of int32_t or int64_t, etc. or mixed types (which will be the case for many binary formats). However the implementation _is_ endian invariant in the sense that if you pass in the same data on big/low endian machines you will receive the same digest.
I'm sorry, of course it is endian invariant since it hashes sequences of octets and therefor endianess is not an issue. What I actually meant was, that in case someone would want to hash custom types, like POD structs, a lot of mindless and error prone code is needed. The most straightforward approach of casting the instance into a array of chars is also the most flawed one, because of uninitialized data in padding bytes and endianess, of course. So the correct solution would be to build a character array by hand, converting values to a defined byte order as necessary. Since your library already provides iterator based hashing, octet iterators would, easily allow hashing user-defined types, performing any conversion that is needed on the fly. Regards, Kimon