Re: [PATCH 03/14] hash: use uint32_t for object_id algorithm

>> I suspect that it would be much more palatable if these functions
>> and struct members are to use a distinct type that is used only by
>> hash algorithm number (your "enum" is fine), that is typedef'ed to
>> be the 32-bit unsigned integer, e.g,
>>
>>     +typedef uint32_t hash_algo_type;
>>     -int hash_algo_by_name(const char *name)
>>     +hash_algo_type hash_algo_by_name(const char *name)
>>
>> Yeah, I know that C does not give us type safety against mixing two
>> different things, both of which are typedef'ed to the same uint32_t,
>> but doing something like the above would still add documentation
>> value.
>
> I'm against passing Rust enum types over the FFI boundary since Rust
> is free to add extra bytes to distinguish between types (and it's
> documented by Rust as not being ABI stable).