Karsten Blees <karsten.bl...@gmail.com> writes:

> Copying the first bytes of a SHA1 is duplicated in six places, however,
> the implications (wrong byte order on little-endian systems) is documented
> only once.

s/wrong /different /; but other than that I think this is a good

> +`unsigned int sha1hash(const unsigned char *sha1)`::
> +
> +     Converts a cryptographic hash (e.g. SHA-1) into an int-sized hash code
> +     for use in hash tables. Cryptographic hashes are supposed to have
> +     uniform distribution, so in contrast to `memhash()`, this just copies
> +     the first `sizeof(int)` bytes without shuffling any bits. Note that
> +     the results will be different on big-endian and little-endian
> +     platforms, so they should not be stored or transferred over the net!

Tone down with s/!/./, perhaps?

Another thing we may want to caution against is to use it as a
tie-breaker that affects the final outcome the user can observe, but
that may be something that goes without saying.  I dunno..

> diff --git a/hashmap.h b/hashmap.h
> index a816ad4..ed5425a 100644
> --- a/hashmap.h
> +++ b/hashmap.h
> @@ -13,6 +13,17 @@ extern unsigned int strihash(const char *buf);
>  extern unsigned int memhash(const void *buf, size_t len);
>  extern unsigned int memihash(const void *buf, size_t len);
> +static inline unsigned int sha1hash(const unsigned char *sha1)
> +{
> +     /*
> +      * Equivalent to 'return *(int *)sha1;', but safe on platforms that
> +      * don't support unaligned reads.
> +      */

s/int/unsigned &/; other than that, the explanation is good.

> +     unsigned int hash;
> +     memcpy(&hash, sha1, sizeof(hash));
> +     return hash;
> +}
> +
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

Reply via email to