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

Martin Ågren [off-list ref] writes:

quoted

+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)

Am Fri, 6 Jul 2018 10:24:58 -0700
schrieb Junio C Hamano [off-list ref]:

Martin Ågren [off-list ref] writes:

quoted

quoted

+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

On Mon, Jul 9, 2018 at 4:22 AM Henning Schild
[off-list ref] wrote:

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.

On Fri, Jul 06, 2018 at 10:24:58AM -0700, Junio C Hamano wrote:

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 think we accidentally did a weather-balloon in e1327023ea (grep:
refactor the concept of "grep source" into an object, 2012-02-02).
It's still there and nobody has complained about it yet.

So I think we can consider that requirement loosened at this point.

-Peff