Re: Refactoring hardcoded SHA-1 constants

From: Duy Nguyen <pclouds@gmail.com>
Date: Apr 19, 2014, 01:12 UTC
Message-ID: <CACsJy8AKQwZ__DdkMQ4jnZ5kDBBVD651wXvQ=8u9TN2oVk17UQ@mail.gmail.com>
In-Reply-To: <xmqqy4z29lg0.fsf@gitster.dls.corp.google.com>

On Sat, Apr 19, 2014 at 8:06 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 17 quoted lines

> Duy Nguyen <pclouds@gmail.com> writes:
>
>> On Sat, Apr 19, 2014 at 7:06 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>>> Let the brainstorming (and bikeshedding) begin!
>>>
>>> 1. GIT_OID_RAWSZ / GIT_OID_HEXSZ
>>>
>>> 2. OID_RAWSZ / OID_HEXSZ
>>>
>>> 3. OID_BINARY_LEN / OID_ASCII_LEN
>>>
>>> 4. BINARY_OID_LEN / ASCII_OID_LEN
>>
>> 5. sizeof(oid) / ASCII_OID_LEN
>
> Can we safely assume sizeof(struct { uchar oid[20]; }) is 20, or on
> some 64-bit platforms do we have to worry about 8-byte alignment?

That's an interesting point. sizeof(that struct) on x86-64 returns 20. I haven't checked about other platforms.

We have some ondisk structures around that contain unsigned char [20] if I remember correctly. Those would need to be handled with care during the conversion if this becomes a real issue.

-- 
Duy