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

["Torsten Bögershausen" <tboegi@web.de>]

On Wed, Aug 16, 2017 at 10:22:39PM +0200, Martin Koegler wrote:
> 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