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

From: Matthew DeVore <matvore@comcast.net>
Date: Jun 3, 2019, 22:39 UTC
Message-ID: <20190603223925.GH4641@comcast.net>
In-Reply-To: <CA+P7+xqqS8wMeNw1E8yXzStNHgrCU5ME1wpWckbPA7pBD3OBHg@mail.gmail.com>

On Mon, Jun 03, 2019 at 03:07:40PM -0700, Jacob Keller wrote:

Show 12 quoted lines

> > +/*
> > + * 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.