Re: Refactoring hardcoded SHA-1 constants

On Sat, Apr 19, 2014 at 8:06 AM, Junio C Hamano wrote: > Duy Nguyen writes: > >> On Sat, Apr 19, 2014 at 7:06 AM, Michael Haggerty >> wrote: >>> Let the brainstorming (and bikeshedding) begin! >>> >>> 1. GIT_OID_RAWSZ / GIT_OID_HEXSZ >>> >>> 2. OID_RAWSZ / OID_HEXSZ >>> >>> 3. OID_BINARY_LEN /

Re: Refactoring hardcoded SHA-1 constants

Duy Nguyen writes: > On Sat, Apr 19, 2014 at 7:06 AM, Michael Haggerty > 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(

Re: Refactoring hardcoded SHA-1 constants

On Sat, Apr 19, 2014 at 7:06 AM, Michael Haggerty 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 -- Duy -- To uns

Re: Refactoring hardcoded SHA-1 constants

> brian m. carlson wrote: >> I'd like to introduce a set of preprocessor constants that we'd use >> instead of hard-coded 20s and 40s everywhere. I agree that it would help code clarity to have symbolic constants for these numbers. On 04/19/2014 12:40 AM, Jonathan Nieder wrote: > Lukewarm on that

Re: Refactoring hardcoded SHA-1 constants

Hi, brian m. carlson wrote: > I'd like to introduce a set of preprocessor constants that we'd use > instead of hard-coded 20s and 40s everywhere. Lukewarm on that. It's hard to do consistently and unless they're named well it can be harder to know what something like BINARY_OBJECT_NAME_LENGTH m

Refactoring hardcoded SHA-1 constants

SHA-1 is clearly on its way out. I know that there has been discussion in the past about moving to different algorithms. I'm not interested in having that discussion now. I'd like to introduce a set of preprocessor constants that we'd use instead of hard-coded 20s and 40s everywhere. That way,