From: Torsten Bögershausen <tboegi@web.de>
Date: Fri, 08 May 2026 19:09:48 GMT
Subject: Re: [PATCH v2 01/11] index-pack, unpack-objects: use size_t for object size
Message-ID: <20260508190947.GA25792@tb-raspi4>
In-Reply-To: <fa39d84b-ddbc-3943-5cca-078fb18db80d@gmx.de>

On Fri, May 08, 2026 at 09:36:53AM +0200, Johannes Schindelin wrote:
> Hi Torsten,
> 
> On Tue, 5 May 2026, Torsten Bögershausen wrote:
> 
> > On Mon, May 04, 2026 at 05:08:18PM +0000, Johannes Schindelin via GitGitGadget wrote:
> > > From: Johannes Schindelin <johannes.schindelin@gmx.de>
> > > 
> > > [...]
> > > @@ -524,7 +524,8 @@ static void *unpack_raw_entry(struct object_entry *obj,
> > >  			      struct object_id *oid)
> > >  {
> > >  	unsigned char *p;
> > > -	unsigned long size, c;
> > > +	size_t size;
> > > +	unsigned long c;
> >
> > Does this look a little bit strange ?
> 
> Good point.
> 
> > p points to an unsigned char (better would be *uint8_t)
> > then it is dereferenced into an "unsigned long".
> > Then it is masked with 0x7f
> > In short: should "c" be declared as uint8_t ?
> 
> Almost. It should be a `size_t`, so that we don't have to cast it when
> shifting it. I'll include a fix in the next iteration.

I think I was not very clear here.
De-referencing a long (or size_t) from any address is something
I would try to avoid:
Some processors do not like to read a 32 or 64 bit value from
an uneven address (and throw an exeption).
x86 processors just handle it, using more than one bus cycle.

In short: Please keep the up-cast and simply read an uint8_t.