Re: [PATCHv3] attr: convert to new threadsafe API

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 19, 2016, 00:06 UTC
Message-ID: <CAPc5daVF2HBD2DfP=w2oG-2PMWQ+guXP_onQX+foSgVYH4N1Qg@mail.gmail.com>
In-Reply-To: <CAGZ79kbS4mP7sVTCM+QJXTwKsgZ40xvVDng-F3igZnJWLYek0A@mail.gmail.com>

On Tue, Oct 18, 2016 at 4:52 PM, Stefan Beller <sbeller@google.com> wrote:

Show 8 quoted lines

>
> >
> > By the way, I do see a merit on the "check" side (tl;dr: but I do
> > not think "result" needs it, hence I do not see the need for the
> > "ugly" variants).
>
> So we'd rather go with const char **result instead of our own new struct there.
> Ok, got it.

I do not think you got it. I am talking about wrapping struct around an array of element, not each element in the array. IOW

Show 7 quoted lines

> > If we were still to do the wrapping for result, I would say that
> > basing it around the FLEX_ARRAY idiom, i.e.
> >
> >>         struct git_attr_result {
> >>                 int num_slots;
> >>                 const char *value[FLEX_ARRAY];
> >>         };

the structure around the array of elements (value) that allows us to have something other than value[] in it. That is what I said "I do not see the need for".

It is perfectly fine future-proofing to have

struct git_attr_result_value {
  const char *value;
};

and have the users of API declare

struct git_attr_result value[5];

or whatever. That way we could fatten the structure later if we wanted to without having to update the users of API, and there is no downside.

Having wrapping strut around the array does have a huge downside, and that is what I said I see no need for.