Am Fri, 6 Jul 2018 10:24:58 -0700
schrieb Junio C Hamano <gits...@pobox.com>:
> Martin Ågren <martin.ag...@gmail.com> 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)
I guess that means the style is acceptable and does not require
changes, please correct me if i am wrong.
Henning
