Re: [RFC PATCH] rev-parse: fix segfault with missing --path-format argument

[Junio C Hamano <gitster@pobox.com>]

Wolfgang Müller <wolf@oriole.systems> writes:

> Calling "git rev-parse --path-format" without an argument segfaults
> instead of giving an error message. Commit fac60b8925 (rev-parse: add
> option for absolute or relative path formatting, 2020-12-13) added the
> argument parsing code but forgot to handle NULL.
>
> Returning an error makes sense here because there is no default value we
> could use. Add a test case to verify.
>
> Signed-off-by: Wolfgang Müller <wolf@oriole.systems>
> ---
> Since this is my first contribution to the project and I'm still
> learning the ropes, I left this patch as RFC.
>
> For a bit of background information, I ran into this expecting the
> following to work:
>
> 	git rev-parse --path-format relative --show-toplevel
>
> I'm unsure how many git subcommands specifically require "=" between the
> option and the argument, but before now I always expected things to
> "just work" when leaving it out.
>
> This fix is based on maint.
>
> Thanks for your time and attention.

Nicely done.

>  builtin/rev-parse.c  | 2 ++
>  t/t1500-rev-parse.sh | 4 ++++
>  2 files changed, 6 insertions(+)
>
> diff --git a/builtin/rev-parse.c b/builtin/rev-parse.c
> index 85bad9052e..7af8dab8bc 100644
> --- a/builtin/rev-parse.c
> +++ b/builtin/rev-parse.c
> @@ -759,6 +759,8 @@ int cmd_rev_parse(int argc, const char **argv, const char *prefix)
>  				continue;
>  			}
>  			if (opt_with_value(arg, "--path-format", &arg)) {
> +				if (!arg)
> +					die("--path-format requires an argument");

As die() is end-user facing, you'd probably want

	die(_("--path-format requires an argument"));

We do have untranslated die() nearby for the same option, which may
want to be cleaned up either in a preliminary patch, or in this same
patch as an unrelated fix "while we are at it".

>  				if (!strcmp(arg, "absolute")) {
>  					format = FORMAT_CANONICAL;
>  				} else if (!strcmp(arg, "relative")) {
> diff --git a/t/t1500-rev-parse.sh b/t/t1500-rev-parse.sh
> index deae916707..a1a8ce5265 100755
> --- a/t/t1500-rev-parse.sh
> +++ b/t/t1500-rev-parse.sh
> @@ -146,6 +146,10 @@ test_expect_success '--path-format can change in the middle of the command line'
>  	test_cmp expect actual
>  '
>  
> +test_expect_success '--path-format does not segfault without an argument' '
> +	test_must_fail git rev-parse --path-format --show-toplevel

The above is certainly worth testing for, but if we ever upgrade the
command line parser of "rev-parse" to be compatible with the parser
based on the parse-options API to allow both "--opt=val" and "--opt
val", it will start to fail for an entirely different reason, namely
"--show-toplevel" will be taken as the argument to "--path-format",
and we'd get "unknown argument to --path-format".  So it might be
prudent to test both, i.e.

	test_must_fail git rev-parse --path-format --show-toplevel &&
	test_must_fail git rev-parse --show-toplevel --path-format