author | Jim Meyering <jim@meyering.net> | |
Wed, 12 Oct 2011 14:33:54 +0000 (16:33 +0200) | ||
committer | Junio C Hamano <gitster@pobox.com> | |
Wed, 12 Oct 2011 19:08:11 +0000 (12:08 -0700) | ||
commit | 2c93286ab2ca5271e26779ffd1ecfd1c7a082a41 | |
tree | ff4f06df6e607c8e11a4857737aa2331713d6492 | tree | snapshot |
parent | 7ed863a85a6ce2c4ac4476848310b8f917ab41f9 | commit | diff |
fix "git apply --index ..." not to deref NULL
I noticed this when "git am CORRUPTED" unexpectedly failed with an
odd diagnostic, and even removed one of the files it was supposed
to have patched.
Reproduce with any valid old/new patch from which you have removed
the "+++ b/FILE" line. You'll see a diagnostic like this
fatal: unable to write file '(null)' mode 100644: Bad address
and you'll find that FILE has been removed.
The above is on glibc-based systems. On other systems, rather than
getting "null", you may provoke a segfault as git tries to
dereference the NULL file name.
Signed-off-by: Jim Meyering <meyering@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
I noticed this when "git am CORRUPTED" unexpectedly failed with an
odd diagnostic, and even removed one of the files it was supposed
to have patched.
Reproduce with any valid old/new patch from which you have removed
the "+++ b/FILE" line. You'll see a diagnostic like this
fatal: unable to write file '(null)' mode 100644: Bad address
and you'll find that FILE has been removed.
The above is on glibc-based systems. On other systems, rather than
getting "null", you may provoke a segfault as git tries to
dereference the NULL file name.
Signed-off-by: Jim Meyering <meyering@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/apply.c | diff | blob | history | |
t/t4254-am-corrupt.sh | [new file with mode: 0755] | blob |