fix: escape more stuff in quoted filenames - #42
Merged
Conversation
diffy currently rejects `\a`, `\b`, `\f`, `\v` as `InvalidEscapedChar`. Both git apply and GNU patch decode them. Observed with git 2.53.0: ```console $ printf 'x' > "$(printf 'f\x07')" && git add -A $ git diff --cached --name-only "f\a" ``` Observed with GNU patch 2.7.1: ```console $ patch -p0 < test.patch # with +++ "bel\a" patching file bel<BEL> ```
24 tasks
weihangloforce-pushed
the
fix
branch
2 times, most recently
from
April 7, 2026 05:31
cb7be49 to
819eff7CompareDiffy misparsed `\0` as standalone NUL instead of the start of a 3-digit octal sequence, so `\033` becomes NUL + "33". Both git apply and GNU patch decode `\033` as ESC (0x1B). Observed with git 2.53.0: ``` $ printf 'x' > "$(printf 'f\033')" && git add -A $ git diff --cached | grep '+++' +++ "b/f\033" ``` Observed with GNU patch 2.7.1: ``` $ patch -p1 < test.patch # with +++ "b/tl\033" patching file tl<ESC> ``` Found via llvm/llvm-project full-history replay (commits 17af06ba..229c95ab, 6c031780..0683a1e5). Note that compat test is not added here and deferred because misparsed NUL path panics the test harness at filesystem level.
Git uses C-style named escapes for certain control characters in quoted filenames. Observed with git 2.53.0 and GNU patch 2.7.1: ```console $ printf 'x' > "$(printf 'f\x07')" && git add -A $ git diff --cached --name-only "f\a" ``` ```console $ patch -p0 < test.patch # with +++ "bel\a" patching file bel<BEL> ```
Git encodes bytes without a named escape as 3-digit octal sequences. Observed with git 2.53.0: ```console $ printf 'x' > "$(printf 'f\033')" && git add -A $ git diff --cached | grep '+++' +++ "b/f\033" ``` GNU patch 2.7.1 also decodes `\033` correctly. It segfaults on malformed `\0` followed by non-octal digits, confirming `\0` is never a standalone escape. Previously, `_escaped_filename()` treated `\0` as standalone NUL (0x00), so `\033` was misparsed as NUL + literal "33". This produced filenames with embedded NUL bytes, which are invalid on all major filesystems. We now replace the `b'0' => b'\0'` arm with a 3-digit octal parser to match the observed git and GNU patch behavior: first digit 0–3, followed by exactly two octal digits 0–7. Found via full-history replay test against llvm/llvm-project (commits 17af06ba..229c95ab, 6c031780..0683a1e5).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
diffy currently rejects
\a,\b,\f,\v, and\0asInvalidEscapedChar.Both git apply and GNU patch decode them.
Observed with git 2.53.0:
Observed with GNU patch 2.7.1:
Observed with git 2.53.0:
GNU patch 2.7.1 also decodes
\033correctly. It segfaults on malformed\0followed by non-octal digits, confirming\0is never a standalone escape.Previously,
_escaped_filename()treated\0as standalone NUL (0x00), so\033was misparsed as NUL + literal "33". This produced filenames with embedded NUL bytes, which are invalid on all major filesystems.We now replace the
b'0' => b'\0'arm with a 3-digit octal parser to match the observed git and GNU patch behavior: first digit 0–3, followed by exactly two octal digits 0–7.See also https://git-scm.com/docs/git-config#Documentation/git-config.txt-corequotePath