Re: [PATCH] strbuf: use designated initializers in STRBUF_INIT

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 14, 2017, 16:11 UTC
Message-ID: <xmqqlgnrq9qi.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <xmqqy3rw3rc8.fsf@gitster.mtv.corp.google.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 6 quoted lines

> Oh, absolutely.
>
> Here is another possible test balloon, that may actually be useful
> as an example.  I think there is a topic in flight that touches this
> array, unfortunately, so I probably would find another one that is
> more stable for a real follow-up patch to the one from Peff.

And here it is.

As to other things that we currently not allow in our codebase that newer compilers can grok, here is what *I* think. It is *not* meant to be an exhaustive "what's new in C99 that is not in C89? what is the final verdict on each of them?":

 - There were occasional cases where we wished if variable-length
   arrays, flexible array members and variadic macros were available
   in our codebase during the course of this project.  We would
   probably want to add a similar test baloon patch for each of
   them to this series that is currently two-patch long.

 - I prefer to keep decl-after-statement out of our codebase.  I
   view it as a big plus in code-readability to be able to see a
   complete list of variables that will be used in a block upfront
   before starting to read the code that uses them.

 - Corollary to the above, I do not mind to have a variable
   declaration in the initialization clause of a for() statement
   (e.g. "for (int i = 0; i < 4; i++) { ... }"), as the scoping rule
   is very sensible.  Some of our "for()" statements use the value
   of the variable after iteration, for which this new construct
   cannot be used, though.

 - This may be showing I am not just old fashioned but also am
   ignorant, but I do not see much point in using the following in
   our codebase (iow, I am not aware of places in the existing code
   that they can be improved by employing these features):

   . // comments
   . restricted pointers
   . static and type qualifiers in parameter array declarators

-- >8 --
Subject: [PATCH] clean.c: use designated initializer

This is another test balloon to see if we get complaints from people whose compilers do not support designated initializer for arrays.

The use of the feature is not all that interesting for cases like the one this patch touches, where the initialized elements of the array is dense, but it would be nice if we can use the feature to initialize an array that has elements initialized to interesting values only sparsely.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 builtin/clean.c | 19 ++++++++++---------
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/builtin/clean.c b/builtin/clean.c
index 057fc97fe4..858df2c4ee 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -33,15 +33,6 @@ static const char *msg_skip_git_dir = N_("Skipping repository %s\n");
 static const char *msg_would_skip_git_dir = N_("Would skip repository %s\n");
 static const char *msg_warn_remove_failed = N_("failed to remove %s");
 
-static int clean_use_color = -1;
-static char clean_colors[][COLOR_MAXLEN] = {
-	GIT_COLOR_RESET,
-	GIT_COLOR_NORMAL,	/* PLAIN */
-	GIT_COLOR_BOLD_BLUE,	/* PROMPT */
-	GIT_COLOR_BOLD,		/* HEADER */
-	GIT_COLOR_BOLD_RED,	/* HELP */
-	GIT_COLOR_BOLD_RED,	/* ERROR */
-};
 enum color_clean {
 	CLEAN_COLOR_RESET = 0,
 	CLEAN_COLOR_PLAIN = 1,
@@ -51,6 +42,16 @@ enum color_clean {
 	CLEAN_COLOR_ERROR = 5
 };
 
+static int clean_use_color = -1;
+static char clean_colors[][COLOR_MAXLEN] = {
+	[CLEAN_COLOR_RESET] = GIT_COLOR_RESET,
+	[CLEAN_COLOR_PLAIN] = GIT_COLOR_NORMAL,
+	[CLEAN_COLOR_PROMPT] = GIT_COLOR_BOLD_BLUE,
+	[CLEAN_COLOR_HEADER] = GIT_COLOR_BOLD,
+	[CLEAN_COLOR_HELP] = GIT_COLOR_BOLD_RED,
+	[CLEAN_COLOR_ERROR] = GIT_COLOR_BOLD_RED,
+};
+
 #define MENU_OPTS_SINGLETON		01
 #define MENU_OPTS_IMMEDIATE		02
 #define MENU_OPTS_LIST_ONLY		04

-- 
2.14.0-rc0-148-g5448d1895b