summaryrefslogtreecommitdiff
path: root/tests/diff/parse.c
diff options
context:
space:
mode:
authorPatrick Steinhardt <ps@pks.im>2019-03-29 12:15:20 +0100
committerPatrick Steinhardt <ps@pks.im>2019-03-29 12:51:23 +0100
commitb3497344fa591c98091bf2d68caed6d7edfa8d01 (patch)
treefb392f407335aba96b718b0457e8fade04741b7e /tests/diff/parse.c
parent131cd9b16dbfc4f5c3b5ba0f44e9285cea4ad5ac (diff)
downloadlibgit2-b3497344fa591c98091bf2d68caed6d7edfa8d01.tar.gz
patch_parse: fix parsing addition/deletion of file with space
The diff header format is a strange beast in that it is inherently unparseable in an unambiguous way. While parsing a/file.txt b/file.txt is obvious and trivially doable, parsing a diff header of a/file b/file ab.txt b/file b/file ab.txt is not (but in fact valid and created by git.git). Due to that, we have relaxed our diff header parser in commit 80226b5f6 (patch_parse: allow parsing ambiguous patch headers, 2017-09-22), so that we started to bail out when seeing diff headers with spaces in their file names. Instead, we try to use the "---" and "+++" lines, which are unambiguous. In some cases, though, we neither have a useable file name from the header nor from the "---" or "+++" lines. This is the case when we have a deletion or addition of a file with spaces: the header is unparseable and the other lines will simply show "/dev/null". This trips our parsing logic when we try to extract the prefix (the "a/" part) that is being used in the path line, where we unconditionally try to dereference a NULL pointer in such a scenario. We can fix this by simply not trying to parse the prefix in cases where we have no useable path name. That'd leave the parsed patch without either `old_prefix` or `new_prefix` populated. But in fact such cases are already handled by users of the patch object, which simply opt to use the default prefixes in that case.
Diffstat (limited to 'tests/diff/parse.c')
0 files changed, 0 insertions, 0 deletions