Junio C Hamano <gitster@xxxxxxxxx> writes:
> 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@xxxxxxxxx>
---
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
