Martin Ågren <martin.agren@xxxxxxxxx> writes:
>> +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)
