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