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

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 9, 2018, 15:47 UTC
Message-ID: <xmqqy3ekfm2r.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <CAPig+cQyXC2o4fUARL_kqPn5+6adBpr+WUfAWWgu2QLjDn1eoQ@mail.gmail.com>

Eric Sunshine <sunshine@sunshineco.com> writes:

Show 32 quoted lines

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

I am not sure I agree with that reasoning. The primary benefit we gain from the convention to allow trailing comma in struct/array initializers like these is that we can add a new field with a patch like this:

	 struct {
	 	char *foo;
	 	char *bar;
	+	char *baz;
	 } xyzzy = {
	 	"foo",
	 	"bar",
	+	"baz",
	 };

without having to touch the initialization of the field that used to be at the end, i.e. .bar="bar", and just can add the new stuff at the end. But that is only possible as long as we allow the trailing comma after the last element. The same argument applies to an array initialization (i.e. when we need to allow more elements to the .extra_args_to_verify[] array).

All of the above is somewhat moot for the other reason I already stated in the thread, though. And that may be a good reason why we would want to lose these trailing commas from the last elements (i.e. if it does not prepare the current code to avoid having to touch the last line when we add a new element at the end, then trailing comma is a visual hiccup that does not serve any useful purpose).