On 03/12/2015 01:26 AM, Junio C Hamano wrote:
> "brian m. carlson" <[email protected]> writes:
>
>> Michael Haggerty recommended that I call the structure element sha1
>> instead of oid in case we want to turn this into a union if we decide to
>> go the additional hash route.
>
> I'd advise against it.
>
> As I wrote in $gmane/265337 in response to Michael:
>
> > 4. We continue to support working with SHA-1s declared to be (unsigned
> > char *) in some performance-critical code, even as we migrate most other
> > code to using SHA-1s embedded within a (struct object_id). This will
> > cost some duplication of code. To accept this approach, we would need an
> > idea of *how much* code duplication would be needed. E.g., how many
> > functions will need both (unsigned char *) versions and (struct
> > object_id *) versions?
>
> ...
>
> I do not know what kind of code duplication you are worried about,
> though. If a callee needs "unsigned char *", the caller that has a
> "struct object_id *o" should pass o->hash to the callee.
>
> And that would break the abstraction effort if you start calling the
> field with a name that is specific to the underlying hash function.
> The caller has to change o->sha1 to o->sha256 instead of keeping
> that as o->oid and letting the callee handle the implementation
> details when calling
>
> if (!hashcmp(o1->oid, o2->oid))
> ; /* they are the same */
> else
> ; /* they are different */
> [...]
Hmm, I guess you imagine that we might sometimes pack SHA-1s, sometimes
SHA-256s (or whatever) in the "oid" field, which would be dimensioned
large enough for either one (with, say, SHA-1s padded with zeros).
I was imagining that this would evolve into a union (or maybe struct) of
different hash types, like
struct object_id {
unsigned char hash_type;
union {
unsigned char sha1[GIT_SHA1_RAWSZ];
unsigned char sha256[GIT_SHA256_RAWSZ];
} hash;
};
BTW in either case, any hopes of mapping object_id objects directly on
top of buffer memory would disappear.
Michael
--
Michael Haggerty
[email protected]
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
