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

From: Jacob Keller <jacob.keller@gmail.com>
Date: Jun 4, 2019, 03:16 UTC
Message-ID: <CA+P7+xp6FYWZA8yXcksw6OiMqiM3Ja5EpVSTbcgeaGD-s+c6=w@mail.gmail.com>
In-Reply-To: <20190603223925.GH4641@comcast.net>

On Mon, Jun 3, 2019 at 3:39 PM Matthew DeVore <matvore@comcast.net> wrote:

Show 19 quoted lines

>
> 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:
>

Ah.. you could do the compiler typeof extensions, but I guess we probably don't wanna rely on that.

>         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.

Ok that makes sense.

Regards, Jake