Re: [PATCH v3 00/36] object_id part 12
- From
brian m. carlson <sandals@crustytoothpaste.net>
- Date
- Mar 15, 2018, 00:53 UTC
- Message-ID
- <20180315005314.GB330384@genre.crustytoothpaste.net>
- In-Reply-To
- <xmqqlgeuzhqe.fsf@gitster-ct.c.googlers.com>
On Wed, Mar 14, 2018 at 10:31:37AM -0700, Junio C Hamano wrote:
Show 24 quoted lines
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
>
> > -+ buf += the_hash_algo->rawsz;
> > -+ size -= the_hash_algo->rawsz;
> > ++ memcpy(it->oid.hash, (const unsigned char*)buf, rawsz);
> > ++ buf += rawsz;
> > ++ size -= rawsz;
> > }
>
> Using memcpy() to stuff the hash[] field of oid structure with a
> bare byte array of rawsz bytes appears twice as a pattern in these
> patches. I wonder if this is something we want to abstract behind
> the API, e.g.
>
> size_t oidstuff_(struct object_id *oid, const unsigned char *buf)
> {
> size_t rawsz = the_hash_algo->rawsz;
> memcpy(oid->hash, buf, rawsz);
> return rawsz;
> }
>
> It just felt a bit uneven to be using a bare-metal memcpy() when
> oidcpy() abstraction releaves the callers from having to be aware of
> the rawsz all the time.Duy suggested oidread and oidwrite, which I can certainly implement. I'm also comfortable with just keeping hashcpy around for these cases if we want.
-- brian m. carlson / brian with sandals: Houston, Texas, US https://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: https://keybase.io/bk2204