From dc29ddebb969af489cdfd5dbbf424710973ef62f Mon Sep 17 00:00:00 2001 From: Johannes Sixt Date: Tue, 9 Aug 2016 16:16:33 +0200 Subject: [PATCH 1/2] config.c: avoid duplicated global static variables Repeating the definition of a static variable seems to be valid in C. Nevertheless, it is bad style because it can cause confusion, definitely when it becomes necessary to change the type. d64ec16 (git config: reorganize to use parseopt, 2009-02-21) added two static variables near the top of the file config.c without removing the definitions of the two variables that occurs later in the file. The two variables were needed earlier in the file in the newly introduced parseopt structure. These references were removed later in d0e08d6 (config: fix parsing of "git config --get-color some.key -1", 2014-11-20). Remove the redundant, younger, definitions near the top of the file and keep the original definitions that occur later. Signed-off-by: Johannes Sixt Signed-off-by: Junio C Hamano --- builtin/config.c | 1 - 1 file changed, 1 deletion(-) diff --git a/builtin/config.c b/builtin/config.c index a58f99c2d7..e4d96313d7 100644 --- a/builtin/config.c +++ b/builtin/config.c @@ -23,7 +23,6 @@ static char term = '\n'; static int use_global_config, use_system_config, use_local_config; static struct git_config_source given_config_source; static int actions, types; -static const char *get_color_slot, *get_colorbool_slot; static int end_null; static int respect_includes = -1; From af920e369778a4cc42519ef523131d29451bf79b Mon Sep 17 00:00:00 2001 From: Johannes Sixt Date: Tue, 9 Aug 2016 16:17:56 +0200 Subject: [PATCH 2/2] commit-slab.h: avoid duplicated global static variables The gigantic define_commit_slab() macro repeats the definition of a static variable that occurs earlier in the macro text. The purpose of the repeated definition at the end of the macro is that it takes the semicolon that occurs where the macro is used. We cannot just remove the first definition of the variable because it is referenced elsewhere in the macro text, and defining the macro later would produce undefined identifier errors. We cannot have a "forward" declaration, either. (This works only with "extern" global variables.) The solution is to use a declaration of a struct that is already defined earlier. This language construct can serve the same purpose as the duplicated static variable definition, but without the confusion. Signed-off-by: Johannes Sixt Signed-off-by: Junio C Hamano --- commit-slab.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/commit-slab.h b/commit-slab.h index f37ec3831f..c10b2539fa 100644 --- a/commit-slab.h +++ b/commit-slab.h @@ -102,16 +102,16 @@ static MAYBE_UNUSED elemtype *slabname## _at(struct slabname *s, \ return &s->slab[nth_slab][nth_slot * s->stride]; \ } \ \ -static int stat_ ##slabname## realloc +struct slabname /* - * Note that this seemingly redundant second declaration is required + * Note that this redundant forward declaration is required * to allow a terminating semicolon, which makes instantiations look * like function declarations. I.e., the expansion of * * define_commit_slab(indegree, int); * - * ends in 'static int stat_indegreerealloc;'. This would otherwise + * ends in 'struct indegree;'. This would otherwise * be a syntax error according (at least) to ISO C. It's hard to * catch because GCC silently parses it by default. */