git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Stefan Beller <sbeller@google.com>
Date
Oct 19, 2016, 00:20 UTC
Message-ID
<CAGZ79kbq7m6s5s8OCXFwyonUdiaL3nVNCoGS40xkH2qKCkYzag@mail.gmail.com>
In-Reply-To
<CAPc5daVF2HBD2DfP=w2oG-2PMWQ+guXP_onQX+foSgVYH4N1Qg@mail.gmail.com>
On Tue, Oct 18, 2016 at 5:06 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 41 quoted lines
> On Tue, Oct 18, 2016 at 4:52 PM, Stefan Beller <sbeller@google.com> wrote:
>>
>> >
>> > 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
>
>> > 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.

I am not sure if I see the upside on wrapping a single value except for its future proofness, i.e. what if we want to transport information that is valid for all values, e.g. an error code or that the result check was done lazily (for non lazy you would need to do X) or ...

IOW I would expect there to be more use cases for information regarding all the values and not each value enhanced by a thing.

We could just repeat the thing in each of the 5 values in
> struct git_attr_result value[5];
though.
I'll go with that.
Previous: Junio C HamanoNext: Junio C Hamano
Message 8 of 9 in “[PATCHv3] attr: convert to new threadsafe API”
  1. Stefan BellerOct 12, 2016
  2. Junio C HamanoOct 12, 2016
  3. Stefan BellerOct 13, 2016
  4. Stefan BellerOct 13, 2016
  5. Junio C HamanoOct 14, 2016
  6. Stefan BellerOct 18, 2016
  7. Junio C HamanoOct 19, 2016
  8. Stefan BellerOct 19, 2016
  9. Junio C HamanoOct 19, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.