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
