Thread (1 message) 1 message, 1 author, 2018-07-09

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

From: Junio C Hamano <hidden>
Date: 2018-07-09 15:47:14

Eric Sunshine [off-list ref] writes:
On Mon, Jul 9, 2018 at 4:22 AM Henning Schild
[off-list ref] wrote:
quoted
Am Fri, 6 Jul 2018 10:24:58 -0700
schrieb Junio C Hamano [off-list ref]:
quoted
Martin Ågren [off-list ref] writes:
quoted
quoted
+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).


Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help