git/xdiff-interface.c, branch v2.13.2

Merge branch 'js/regexec-buf'

2016-09-26T23:09:19Z

Some codepaths in "git diff" used regexec(3) on a buffer that was mmap(2)ed, which may not have a terminating NUL, leading to a read beyond the end of the mapped region. This was fixed by introducing a regexec_buf() helper that takes a pair with REG_STARTEND extension. * js/regexec-buf: regex: use regexec_buf() regex: add regexec_buf() that can work on a non NUL-terminated string regex: -G feeds a non NUL-terminated string to regexec() and fails

regex: use regexec_buf()

2016-09-21T20:56:15Z

The new regexec_buf() function operates on buffers with an explicitly specified length, rather than NUL-terminated strings. We need to use this function whenever the buffer we want to pass to regexec(3) may have been mmap(2)ed (and is hence not NUL-terminated). Note: the original motivation for this patch was to fix a bug where `git diff -G ` would crash. This patch converts more callers, though, some of which allocated to construct NUL-terminated strings, or worse, modified buffers to temporarily insert NULs while calling regexec(3). By converting them to use regexec_buf(), the code has become much cleaner. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

Convert read_mmblob to take struct object_id.

2016-09-07T19:59:42Z

Since all of its callers have been updated, convert read_mmblob to take a pointer to struct object_id. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

xdiff: don't trim common tail with -W

2016-05-31T20:08:56Z

The function trim_common_tail() exits early if context lines are requested. If -U0 and -W are specified together then it can still trim context lines that might belong to a changed function. As a result that function is shown incompletely. Fix that by calling trim_common_tail() only if no function context or fixed context is requested. The parameter ctx is no longer needed now; remove it. While at it fix an outdated comment as well. Signed-off-by: Rene Scharfe Signed-off-by: Junio C Hamano

convert trivial cases to ALLOC_ARRAY

2016-02-22T22:51:09Z

Each of these cases can be converted to use ALLOC_ARRAY or REALLOC_ARRAY, which has two advantages: 1. It automatically checks the array-size multiplication for overflow. 2. It always uses sizeof(*array) for the element-size, so that it can never go out of sync with the declared type of the array. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

xdiff: reject files larger than ~1GB

2015-09-28T21:57:23Z

The xdiff code is not prepared to handle extremely large files. It uses "int" in many places, which can overflow if we have a very large number of lines or even bytes in our input files. This can cause us to produce incorrect diffs, with no indication that the output is wrong. Or worse, we may even underallocate a buffer whose size is the result of an overflowing addition. We're much better off to tell the user that we cannot diff or merge such a large file. This patch covers both cases, but in slightly different ways: 1. For merging, we notice the large file and cleanly fall back to a binary merge (which is effectively "we cannot merge this"). 2. For diffing, we make the binary/text distinction much earlier, and in many different places. For this case, we'll use the xdi_diff as our choke point, and reject any diff there before it hits the xdiff code. This means in most cases we'll die() immediately after. That's not ideal, but in practice we shouldn't generally hit this code path unless the user is trying to do something tricky. We already consider files larger than core.bigfilethreshold to be binary, so this code would only kick in when that is circumvented (either by bumping that value, or by using a .gitattribute to mark a file as diffable). In other words, we can avoid being "nice" here, because there is already nice code that tries to do the right thing. We are adding the suspenders to the nice code's belt, so notice when it has been worked around (both to protect the user from malicious inputs, and because it is better to die() than generate bogus output). The maximum size was chosen after experimenting with feeding large files to the xdiff code. It's just under a gigabyte, which leaves room for two obvious cases: - a diff3 merge conflict result on files of maximum size X could be 3*X plus the size of the markers, which would still be only about 3G, which fits in a 32-bit int. - some of the diff code allocates arrays of one int per record. Even if each file consists only of blank lines, then a file smaller than 1G will have fewer than 1G records, and therefore the int array will fit in 4G. Since the limit is arbitrary anyway, I chose to go under a gigabyte, to leave a safety margin (e.g., we would not want to overflow by allocating "(records + 1) * sizeof(int)" or similar. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

xdiff: remove emit_func() and xdi_diff_hunks()

2012-05-09T21:08:42Z

The functions are unused now, remove them. Signed-off-by: Rene Scharfe Signed-off-by: Junio C Hamano

add, merge, diff: do not use strcasecmp to compare config variable names

2011-05-15T01:53:39Z

The config machinery already makes section and variable names lowercase when parsing them, so using strcasecmp for comparison just feels wasteful. No noticeable change intended. Noticed-by: Jay Soffian Signed-off-by: Jonathan Nieder Signed-off-by: Junio C Hamano

Merge branch 'rs/maint-diff-fd-leak' into maint

2010-12-26T19:18:39Z

* rs/maint-diff-fd-leak: close file on error in read_mmfile()

close file on error in read_mmfile()

2010-12-26T19:17:18Z

Reported in http://qa.debian.org/daca/cppcheck/sid/git_1.7.2.3-2.2.html and in http://thread.gmane.org/gmane.comp.version-control.git/123042. Signed-off-by: Rene Scharfe Signed-off-by: Junio C Hamano