On Sat, Oct 28, 2017 at 11:12 AM, brian m. carlson
<sandals@xxxxxxxxxxxxxxxxxxxx> wrote:
> Since in the future we want to support an additional hash algorithm, add
> a structure that represents a hash algorithm and all the data that must
> go along with it. Add a constant to allow easy enumeration of hash
> algorithms. Implement function typedefs to create an abstract API that
> can be used by any hash algorithm, and wrappers for the existing SHA1
> functions that conform to this API.
>
> Expose a value for hex size as well as binary size. While one will
> always be twice the other, the two values are both used extremely
> commonly throughout the codebase and providing both leads to improved
> readability.
>
> Don't include an entry in the hash algorithm structure for the null
> object ID. As this value is all zeros, any suitably sized all-zero
> object ID can be used, and there's no need to store a given one on a
> per-hash basis.
>
> The current hash function transition plan envisions a time when we will
> accept input from the user that might be in SHA-1 or in the NewHash
> format. Since we cannot know which the user has provided, add a
> constant representing the unknown algorithm to allow us to indicate that
> we must look the correct value up.
Cool.
> +
> +const struct git_hash_algo hash_algos[GIT_HASH_NALGOS] = {
> + {
> + NULL,
> + 0x00000000,
> + 0,
> + 0,
> + 0,
> + NULL,
> + NULL,
> + NULL,
> + NULL,
> + NULL,
If we are fancy we could provide an appropriate die() call
as the function pointers. That way if you call these functions
by accident, you get a well worded warning instead of a segfault.
