Re: [PATCH v2 8/9] list-objects-filter-options: clean up use of ALLOC_GROW

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jun 03, 2019 at 03:07:40PM -0700, Jacob Keller wrote:
> > +/*
> > + * Similar to ALLOC_GROW but handles updating of the nr value and
> > + * zeroing the bytes of the newly-grown array elements.
> > + *
> > + * DO NOT USE any expression with side-effect for any of the
> > + * arguments.
> > + */
> 
> Since ALLOC_GROW already doesn't handle this safely, there isn't
> necessarily a reason to fix it, but you could read the macro values
> into temporary variables inside the do { } while(0) loop in order to
> avoid the multiple-expansion side effect issues...

For x I don't think that's possible since we don't know the pointer type. For
nr and alloc it doesn't make sense since they're being assigned to. For
`increase` I could try this:

	size_t ALLOC_GROW_BY__increase = (increase);

but I'm not sure how well this works when `increase` is a signed type. This
seemed sufficiently pitfall-y that I didn't attempt it. Relatedly, I was
thinking something like this would be nice, if anyone has time for such a
refactor:

struct growth_info {
	size_t nr, alloc;
}

And use that to replace individual "size_t foo_nr, foo_alloc"

And make ALLOC_GROW_BY use it. I think a bulk, maybe even most, ALLOC_GROW
invocations can be changed to ALLOC_GROW_BY.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux