Commit db5dfa33 authored by Johannes Schindelin's avatar Johannes Schindelin Committed by Junio C Hamano

regex: -G<pattern> feeds a non NUL-terminated string to regexec() and fails

When our pickaxe code feeds file contents to regexec(), it implicitly
assumes that the file contents are read into implicitly NUL-terminated
buffers (i.e. that we overallocate by 1, appending a single '\0').

This is not so.

In particular when the file contents are simply mmap()ed, we can be
virtually certain that the buffer is preceding uninitialized bytes, or
invalid pages.

Note that the test we add here is known to be flakey: we simply cannot
know whether the byte following the mmap()ed ones is a NUL or not.

Typically, on Linux the test passes. On Windows, it fails virtually
every time due to an access violation (that's a segmentation fault for
you Unix-y people out there). And Windows would be correct: the
regexec() call wants to operate on a regular, NUL-terminated string,
there is no NUL in the mmap()ed memory range, and it is undefined
whether the next byte is even legal to access.

When run with --valgrind it demonstrates quite clearly the breakage, of

Being marked with `test_expect_failure`, this test will sometimes be
declare "TODO fixed", even if it only passes by mistake.

This test case represents a Minimal, Complete and Verifiable Example of
a breakage reported by Chris Sidi.
Signed-off-by: Johannes Schindelin's avatarJohannes Schindelin <>
Signed-off-by: default avatarJunio C Hamano <>
parent 0b65a8db
# Copyright (c) 2016 Johannes Schindelin
test_description='Pickaxe options'
. ./
test_expect_success setup '
test_commit initial &&
printf "%04096d" 0 >4096-zeroes.txt &&
git add 4096-zeroes.txt &&
test_tick &&
git commit -m "A 4k file"
test_expect_failure '-G matches' '
git diff --name-only -G "^0{4096}$" HEAD^ >out &&
test 4096-zeroes.txt = "$(cat out)"
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment