Re: [PATCH 4/8] gpg-interface: introduce an abstraction for multiple gpg formats
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jul 6, 2018, 17:24 UTC
- Message-ID
- <xmqqa7r4mg45.fsf@gitster-ct.c.googlers.com>
- In-Reply-To
- <CAN0heSrXpLCDRjnZC80QXBG27gd6m5reBn1hfNd_KXxnPVkA2g@mail.gmail.com>
Martin Ågren <martin.agren@gmail.com> writes:
Show 14 quoted lines
>> +enum gpgformats { PGP_FMT };
>> +struct gpg_format_data gpg_formats[] = {
>> + { .format = "PGP", .program = "gpg",
>> + .extra_args_verify = { "--keyid-format=long", },
>> + .sigs = { PGP_SIGNATURE, PGP_MESSAGE, },
>> + },
>> +};
>
> I think those trailing commas are ok now, but I'm not sure...
>
> I had the same thought about designated initializers. Those should be ok
> now, c.f. cbc0f81d96 (strbuf: use designated initializers in STRBUF_INIT,
> 2017-07-10) and a73b3680c4 (Add and use generic name->id mapping code
> for color slot parsing, 2018-05-26).As you said, we dipped our toes in designated initializers in both struct and array, i.e. { .field = init }, { [offset] = init } last summer and we haven't got complaints from minor platforms so far.
The "comma" thing you are wondering is something else. The comma we see above is after the last element in an array's initializer (and the last element in a struct's initializer), which we have been happily using from very early days (and they are kosher ANSI C).
What we've been avoiding was the comma after the last element in the enum (in other words, if PGP_FMT had ',' after it in the above quoted addition, that would have been violation of that rule), as having such a trailing comma used to be ANSI C violation as well. I do not recall offhand if we loosened that deliberately.
4b05548f ("enums: omit trailing comma for portability", 2010-05-14), c9b6782a ("enums: omit trailing comma for portability", 2011-03-16)