| Message ID | 20210516120449.661636-1-wolf@oriole.systems (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [RFC] rev-parse: fix segfault with missing --path-format argument | expand |
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
On 2021-05-16 21:53, Junio C Hamano wrote: > 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". I would not mind preparing a preliminary patch that cleans up all untranslated user-facing calls to die(). My editor finds 15 of those in rev-parse.c, and I think they all qualify. If you'd rather not touch unrelated code paths I'll instead include it in v2 as an unrelated fix in the same commit. > 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 I think I initially went for "--path-format --show-toplevel" because I was under the assumption that --path-format needs another option it can modify. It seems that this is not the case, so wouldn't it be simpler here to do the following instead: test_must_fail git rev-parse --path-format That way we do not have to worry about subsequent changes to other, unrelated, options.
Wolfgang Müller <wolf@oriole.systems> writes: > On 2021-05-16 21:53, Junio C Hamano wrote: > >> 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". > > I would not mind preparing a preliminary patch that cleans up all > untranslated user-facing calls to die(). My editor finds 15 of those in > rev-parse.c, and I think they all qualify. > > If you'd rather not touch unrelated code paths I'll instead include it > in v2 as an unrelated fix in the same commit. I am puzzled by the last paragraph. Somebody who does not want to see "unrelated" codepaths touched would appreciate if a commit that fixes this segfault does not touch them at the same time. In any case, I now counted existing die() messages in this file, and among 15 of them, only 1 is marked with _(...). I think that it is the best to apply the patch as-is (without _(...)), adding one untranslated message to the file. Then, on top of this change, the 15 untranslated messages can be marked with _(...) a separate commit (and it does not even have to be done by you). > I think I initially went for "--path-format --show-toplevel" because I > was under the assumption that --path-format needs another option it can > modify. It seems that this is not the case, so wouldn't it be simpler > here to do the following instead: > > test_must_fail git rev-parse --path-format > > That way we do not have to worry about subsequent changes to other, > unrelated, options. That's good, too. Simple. Thanks.
On 2021-05-17 06:59, Junio C Hamano wrote: > >> 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". > > > > I would not mind preparing a preliminary patch that cleans up all > > untranslated user-facing calls to die(). My editor finds 15 of those > > in rev-parse.c, and I think they all qualify. > > > > If you'd rather not touch unrelated code paths I'll instead include > > it in v2 as an unrelated fix in the same commit. > > I am puzzled by the last paragraph. Somebody who does not want to see > "unrelated" codepaths touched would appreciate if a commit that fixes > this segfault does not touch them at the same time. Apologies, I was being unclear here. I was meaning to offer either cleaning up all calls to die() in a separate patch, or fixing only the nearby occurrence that you mentioned in the same patch. I had implicitly assumed you had seen the other untranslated messages already but only wanted to fix the one for the same option (ie in a nearby, "related" path). > In any case, I now counted existing die() messages in this file, and > among 15 of them, only 1 is marked with _(...). I think that it > is the best to apply the patch as-is (without _(...)), adding one > untranslated message to the file. Will do. > Then, on top of this change, the 15 untranslated messages can be > marked with _(...) a separate commit (and it does not even have to > be done by you). I don't mind doing this, so I'll include it. > That's good, too. Simple. > > Thanks. Thanks a lot for your feedback, I'll be sending v2 along shortly.
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"); 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 +' + test_expect_success 'git-common-dir from worktree root' ' echo .git >expect && git rev-parse --git-common-dir >actual &&
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. builtin/rev-parse.c | 2 ++ t/t1500-rev-parse.sh | 4 ++++ 2 files changed, 6 insertions(+)