Re: [PATCH 4/8] gpg-interface: introduce an abstraction for multiple gpg formats

[Eric Sunshine <sunshine@sunshineco.com>]

On Mon, Jul 9, 2018 at 4:22 AM Henning Schild
<henning.schild@siemens.com> wrote:
> Am Fri, 6 Jul 2018 10:24:58 -0700
> schrieb Junio C Hamano <gitster@pobox.com>:
> > Martin Ågren <martin.agren@gmail.com> writes:
> > >> +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...
> >
> > 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 guess that means the style is acceptable and does not require
> changes, please correct me if i am wrong.

The trailing comma in the 'sigs' initializer is bothersome because
'sigs' is declared as a 2-element array, and this initializer already
has two elements. Therefore, the comma is misleading to anyone reading
the code, making it appears as if additional items can be added. For
that reason, alone, it would be nice to see the unnecessary comma
removed.

Ditto with regard to the trailing comma in the 'extra_args_verify'
initializer since 'extra_args_verify' is declared as a 1-element
array.