[PATCH] builtin/config: work around an unsized array forward declaration

[PATCH] builtin/config: work around an unsized array forward declaration

[Beat Bolli]

As reported here[0], Microsoft Visual Studio 2017.2 and "gcc -pedantic"
don't understand the forward declaration of an unsized static array.
They insist on an array size:

    d:\git\src\builtin\config.c(70,46): error C2133: 'builtin_config_options': unknown size

The thread [1] explains that this is due to the single-pass nature of
old compilers.

To work around this error, introduce the forward-declared function
usage_builtin_config() instead that uses the array
builtin_config_options only after it has been defined.

Also use this function in all other places where usage_with_options() is
called with the same arguments.

[0]: https://github.com/git-for-windows/git/issues/1735
[1]: https://groups.google.com/forum/#!topic/comp.lang.c.moderated/bmiF2xMz51U

Fixes https://github.com/git-for-windows/git/issues/1735

Reported-By: Karen Huang (via GitHub)
Signed-off-by: Beat Bolli <dev+git@drbeat.li>
---
 builtin/config.c | 27 +++++++++++++++------------
 1 file changed, 15 insertions(+), 12 deletions(-)

diff --git a/builtin/config.c b/builtin/config.c
index b29d26dede..2c93a289a7 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -67,7 +67,7 @@ static int show_origin;
 	{ OPTION_CALLBACK, (s), (l), (v), NULL, (h), PARSE_OPT_NOARG | \
 	PARSE_OPT_NONEG, option_parse_type, (i) }
 
-static struct option builtin_config_options[];
+static NORETURN void usage_builtin_config(void);
 
 static int option_parse_type(const struct option *opt, const char *arg,
 			     int unset)
@@ -111,8 +111,7 @@ static int option_parse_type(const struct option *opt, const char *arg,
 		 * --type=int'.
 		 */
 		error("only one type at a time.");
-		usage_with_options(builtin_config_usage,
-			builtin_config_options);
+		usage_builtin_config();
 	}
 	*to_type = new_type;
 
@@ -157,11 +156,16 @@ static struct option builtin_config_options[] = {
 	OPT_END(),
 };
 
+static NORETURN void usage_builtin_config(void)
+{
+	usage_with_options(builtin_config_usage, builtin_config_options);
+}
+
 static void check_argc(int argc, int min, int max) {
 	if (argc >= min && argc <= max)
 		return;
 	error("wrong number of arguments");
-	usage_with_options(builtin_config_usage, builtin_config_options);
+	usage_builtin_config();
 }
 
 static void show_config_origin(struct strbuf *buf)
@@ -596,7 +600,7 @@ int cmd_config(int argc, const char **argv, const char *prefix)
 	if (use_global_config + use_system_config + use_local_config +
 	    !!given_config_source.file + !!given_config_source.blob > 1) {
 		error("only one config file at a time.");
-		usage_with_options(builtin_config_usage, builtin_config_options);
+		usage_builtin_config();
 	}
 
 	if (use_local_config && nongit)
@@ -660,12 +664,12 @@ int cmd_config(int argc, const char **argv, const char *prefix)
 
 	if ((actions & (ACTION_GET_COLOR|ACTION_GET_COLORBOOL)) && type) {
 		error("--get-color and variable type are incoherent");
-		usage_with_options(builtin_config_usage, builtin_config_options);
+		usage_builtin_config();
 	}
 
 	if (HAS_MULTI_BITS(actions)) {
 		error("only one action at a time.");
-		usage_with_options(builtin_config_usage, builtin_config_options);
+		usage_builtin_config();
 	}
 	if (actions == 0)
 		switch (argc) {
@@ -673,25 +677,24 @@ int cmd_config(int argc, const char **argv, const char *prefix)
 		case 2: actions = ACTION_SET; break;
 		case 3: actions = ACTION_SET_ALL; break;
 		default:
-			usage_with_options(builtin_config_usage, builtin_config_options);
+			usage_builtin_config();
 		}
 	if (omit_values &&
 	    !(actions == ACTION_LIST || actions == ACTION_GET_REGEXP)) {
 		error("--name-only is only applicable to --list or --get-regexp");
-		usage_with_options(builtin_config_usage, builtin_config_options);
+		usage_builtin_config();
 	}
 
 	if (show_origin && !(actions &
 		(ACTION_GET|ACTION_GET_ALL|ACTION_GET_REGEXP|ACTION_LIST))) {
 		error("--show-origin is only applicable to --get, --get-all, "
 			  "--get-regexp, and --list.");
-		usage_with_options(builtin_config_usage, builtin_config_options);
+		usage_builtin_config();
 	}
 
 	if (default_value && !(actions & ACTION_GET)) {
 		error("--default is only applicable to --get");
-		usage_with_options(builtin_config_usage,
-			builtin_config_options);
+		usage_builtin_config();
 	}
 
 	if (actions & PAGING_ACTIONS)
-- 
2.15.0.rc1.299.gda03b47c3

Re: [PATCH] builtin/config: work around an unsized array forward declaration

[Taylor Blau]

On Thu, Jul 05, 2018 at 08:34:45PM +0200, Beat Bolli wrote:
> As reported here[0], Microsoft Visual Studio 2017.2 and "gcc -pedantic"
> don't understand the forward declaration of an unsized static array.
> They insist on an array size:
>
>     d:\git\src\builtin\config.c(70,46): error C2133: 'builtin_config_options': unknown size
>
> The thread [1] explains that this is due to the single-pass nature of
> old compilers.
>
> To work around this error, introduce the forward-declared function
> usage_builtin_config() instead that uses the array
> builtin_config_options only after it has been defined.

Argh, I think that this is my fault (via: fb0dc3bac1 (builtin/config.c:
support `--type=<type>` as preferred alias for `--<type>`, 2018-04-18)).

Thank you for the explanation above, and for the patch below. I reviewed
it myself, and the fix seems to be appropriate.

> Also use this function in all other places where usage_with_options() is
> called with the same arguments.
>
> [0]: https://github.com/git-for-windows/git/issues/1735
> [1]: https://groups.google.com/forum/#!topic/comp.lang.c.moderated/bmiF2xMz51U
>
> Fixes https://github.com/git-for-windows/git/issues/1735
>
> Reported-By: Karen Huang (via GitHub)
> Signed-off-by: Beat Bolli <dev+git@drbeat.li>

Thanks,
Taylor

Re: [PATCH] builtin/config: work around an unsized array forward declaration

[Jeff King]

On Thu, Jul 05, 2018 at 08:34:45PM +0200, Beat Bolli wrote:

> As reported here[0], Microsoft Visual Studio 2017.2 and "gcc -pedantic"
> don't understand the forward declaration of an unsized static array.
> They insist on an array size:
> 
>     d:\git\src\builtin\config.c(70,46): error C2133: 'builtin_config_options': unknown size
> 
> The thread [1] explains that this is due to the single-pass nature of
> old compilers.

Right, that makes sense.

> To work around this error, introduce the forward-declared function
> usage_builtin_config() instead that uses the array
> builtin_config_options only after it has been defined.
> 
> Also use this function in all other places where usage_with_options() is
> called with the same arguments.

Your patch is obviously correct, but I think here there might be an even
simpler solution: just bump option_parse_type() below the declaration,
since it's the only one that needs it. That hunk is bigger, but the
overall diff is simpler, and we don't need to carry that extra wrapper
function.

As a general rule for this case (because reordering isn't always an
option), I also wonder if we should prefer just introducing a pointer
alias:

  /* forward declaration is a pointer */
  static struct option *builtin_config_options;

  /* later, declare the actual storage and its alias */
  static struct option builtin_config_options_storage[] = {
	...
  };
  static struct option *builtin_config_options = builtin_config_options_storage;

There are occasionally cases where the caller really wants an array and
not a pointer, but in practice those are pretty rare.

I have a slight preference for the reordering solution in this case, but
any of them would be OK with me.

-Peff

Re: [PATCH] builtin/config: work around an unsized array forward declaration

[Beat Bolli]

Hi Peff

On 05.07.18 21:38, Jeff King wrote:
> On Thu, Jul 05, 2018 at 08:34:45PM +0200, Beat Bolli wrote:
> 
>> As reported here[0], Microsoft Visual Studio 2017.2 and "gcc -pedantic"
>> don't understand the forward declaration of an unsized static array.
>> They insist on an array size:
>>
>>     d:\git\src\builtin\config.c(70,46): error C2133: 'builtin_config_options': unknown size
>>
>> The thread [1] explains that this is due to the single-pass nature of
>> old compilers.
> 
> Right, that makes sense.
> 
>> To work around this error, introduce the forward-declared function
>> usage_builtin_config() instead that uses the array
>> builtin_config_options only after it has been defined.
>>
>> Also use this function in all other places where usage_with_options() is
>> called with the same arguments.
> 
> Your patch is obviously correct, but I think here there might be an even
> simpler solution: just bump option_parse_type() below the declaration,
> since it's the only one that needs it. That hunk is bigger, but the
> overall diff is simpler, and we don't need to carry that extra wrapper
> function.

That was dscho's first try in the GitHub issue. It doesn't compile
because the OPT_CALLBACK* macros in the builtin_config_options
declaration inserts a pointer to option_parse_type into the array items.
We need at least one forward declaration, and my patch seemed the least
intrusive.

> As a general rule for this case (because reordering isn't always an
> option), I also wonder if we should prefer just introducing a pointer
> alias:
> 
>   /* forward declaration is a pointer */
>   static struct option *builtin_config_options;
> 
>   /* later, declare the actual storage and its alias */
>   static struct option builtin_config_options_storage[] = {
> 	...
>   };
>   static struct option *builtin_config_options = builtin_config_options_storage;
> 
> There are occasionally cases where the caller really wants an array and
> not a pointer, but in practice those are pretty rare.
> 
> I have a slight preference for the reordering solution in this case, but
> any of them would be OK with me.
> 
> -Peff 

Regards, Beat

Re: [PATCH] builtin/config: work around an unsized array forward declaration

[Jeff King]

On Thu, Jul 05, 2018 at 09:50:53PM +0200, Beat Bolli wrote:

> > Your patch is obviously correct, but I think here there might be an even
> > simpler solution: just bump option_parse_type() below the declaration,
> > since it's the only one that needs it. That hunk is bigger, but the
> > overall diff is simpler, and we don't need to carry that extra wrapper
> > function.
> 
> That was dscho's first try in the GitHub issue. It doesn't compile
> because the OPT_CALLBACK* macros in the builtin_config_options
> declaration inserts a pointer to option_parse_type into the array items.
> We need at least one forward declaration, and my patch seemed the least
> intrusive.

Ah, right, so it actually is mutually recursive.  Forward-declaring
option_parse_type() would fix it, along with the reordering. I'm
ambivalent between the available options, then; we might as well go with
what you posted, then, since it's already done. :)

-Peff

Re: [PATCH] builtin/config: work around an unsized array forward declaration

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Thu, Jul 05, 2018 at 09:50:53PM +0200, Beat Bolli wrote:
>
>> > Your patch is obviously correct, but I think here there might be an even
>> > simpler solution: just bump option_parse_type() below the declaration,
>> > since it's the only one that needs it. That hunk is bigger, but the
>> > overall diff is simpler, and we don't need to carry that extra wrapper
>> > function.
>> 
>> That was dscho's first try in the GitHub issue. It doesn't compile
>> because the OPT_CALLBACK* macros in the builtin_config_options
>> declaration inserts a pointer to option_parse_type into the array items.
>> We need at least one forward declaration, and my patch seemed the least
>> intrusive.
>
> Ah, right, so it actually is mutually recursive.  Forward-declaring
> option_parse_type() would fix it, along with the reordering. I'm
> ambivalent between the available options, then; we might as well go with
> what you posted, then, since it's already done. :)

Among three, forward declaration of the function with reordering
that nobody has written except for in the brain smells the best, and
turning an array to a pointer that points at a separate storage looked
the worst.  I also am OK with what's already posted, too.

Thanks.

Re: [PATCH] builtin/config: work around an unsized array forward declaration

[Kim Gybels]

On (06/07/18 12:24), Junio C Hamano wrote:
> 
> Jeff King <peff@peff.net> writes:
> 
> > On Thu, Jul 05, 2018 at 09:50:53PM +0200, Beat Bolli wrote:
> >
> >> > Your patch is obviously correct, but I think here there might be an even
> >> > simpler solution: just bump option_parse_type() below the declaration,
> >> > since it's the only one that needs it. That hunk is bigger, but the
> >> > overall diff is simpler, and we don't need to carry that extra wrapper
> >> > function.
> >> 
> >> That was dscho's first try in the GitHub issue. It doesn't compile
> >> because the OPT_CALLBACK* macros in the builtin_config_options
> >> declaration inserts a pointer to option_parse_type into the array items.
> >> We need at least one forward declaration, and my patch seemed the least
> >> intrusive.
> >
> > Ah, right, so it actually is mutually recursive.  Forward-declaring
> > option_parse_type() would fix it, along with the reordering. I'm
> > ambivalent between the available options, then; we might as well go with
> > what you posted, then, since it's already done. :)
> 
> Among three, forward declaration of the function with reordering
> that nobody has written except for in the brain smells the best, and
> turning an array to a pointer that points at a separate storage looked
> the worst.  I also am OK with what's already posted, too.

I posted the forward declaration of the function on the Git for
Windows issue:
https://github.com/git-for-windows/git/issues/1735#issuecomment-402825623

I would consider it the minimal fix. The already posted solution is
also OK for me.

It's also possible to use "extern" instead of "static" for the array.
It would, however, not be my preferred solution.

-Kim