Re: [PATCH 1/9] Convert pack-objects to size_t

From: Torsten Bögershausen <tboegi@web.de>
Date: Aug 17, 2017, 10:38 UTC
Message-ID: <20170817103804.GA18336@tor.lan>
In-Reply-To: <20170816202238.GA3008@mail.zuhause>

On Wed, Aug 16, 2017 at 10:22:39PM +0200, Martin Koegler wrote:

Show 12 quoted lines

> On Mon, Aug 14, 2017 at 10:08:05AM -0700, Junio C Hamano wrote:
> >    It may help reducing the maintenance if we introduced obj_size_t
> >    that is defined to be size_t for now, so that we can later swap
> >    it to ofs_t or some larger type when we know we do need to
> >    support objects whose size cannot be expressed in size_t, but I
> >    do not offhand know what the pros-and-cons with such an approach
> >    would look like.
> 
> Where should the use of obj_size_t end and the use of size_t start? 
> 
> We often determine a object size and then pass it to malloc. 
> We would start with a larger datatyp and then truncate for memory allocation, which use size_t.

The truncation is done with xsize_t:
The "old" sha1_file.c has something like this:
    idx_size = xsize_t(st.st_size);

I personally don't think that obj_size_t gives us so much. There are "objects" which are "on disk", and they may have a length off_t, And there are "objects" loaded into memory, and they have a length size_t. And everybody can check that we use the right type. Additionally I don't like it very much, when object size in memory is counted in a 64 bit value (and this will happen if obj_size_ = off_t == 64bit)

Anyhow, to answer your question: All calles xmalloc() must be prepared like this:

p = xmalloc(xsize_t(size_of_object));

That should do the trick.

> 
> Regards,
> Martin