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

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Jul 9, 2018, 08:44 UTC
Message-ID: <CAPig+cQyXC2o4fUARL_kqPn5+6adBpr+WUfAWWgu2QLjDn1eoQ@mail.gmail.com>
In-Reply-To: <20180709102139.274f0560@md1pvb1c.ad001.siemens.net>

On Mon, Jul 9, 2018 at 4:22 AM Henning Schild <henning.schild@siemens.com> wrote:

Show 19 quoted lines

> 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.