diff options
| author | Jeff King <peff@peff.net> | 2026-03-26 15:04:44 -0400 |
|---|---|---|
| committer | Junio C Hamano <gitster@pobox.com> | 2026-03-26 12:47:17 -0700 |
| commit | 4d5fb9377bba1f45a940e10b0b7354fe7db2b301 (patch) | |
| tree | d4de4053421475777d6d0bc8a391e23bc0333368 /contrib/completion/git-completion.bash | |
| parent | 41688c1a2312f62f44435e1a6d03b4b904b5b0ec (diff) | |
| download | git-4d5fb9377bba1f45a940e10b0b7354fe7db2b301.tar.xz | |
revision: make handle_dotdot() interface less confusing
There are two very subtle bits to the way we parse ".." (and "...")
range operators:
1. In handle_dotdot_1(), we assume that the incoming arguments "dotdot"
and "arg" are part of the same string, with the first digit of the
range-operator blanked to a NUL. Then when we want the full name
(e.g., to report an error), we replace the NUL with a dot to restore
the original string.
2. In handle_dotdot(), we take in a const string, but then we modify it
by overwriting the range operator with a NUL. This has worked OK in
practice since we tend to pass in buffers that are actually
writeable (including argv), but segfaults with something like:
handle_revision_arg("..HEAD", &revs, 0, 0);
On top of that, building with recent versions of glibc causes the
compiler to complain, because it notices when we use strchr() or
strstr() to launder away constness (basically detecting the
possibility of the segfault above via the type system).
Instead of munging the buffer, let's instead make a temporary copy of
the left-hand side of the range operator. That avoids any const
violations, and lets us pass around the parsed elements independently:
the left-hand side, the right-hand side, the number of dots (via the
"symmetric" flag), and the original full string for error messages.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'contrib/completion/git-completion.bash')
0 files changed, 0 insertions, 0 deletions
