git/diff-delta.c, branch jch

git-compat-util: introduce MEMZERO_ARRAY() macro

2025-12-11T05:44:43Z

Introduce a new macro MEMZERO_ARRAY() that zeroes the memory allocated by ALLOC_ARRAY() and friends. And add coccinelle rule to enforce the use of this macro. Signed-off-by: Toon Claes Signed-off-by: Junio C Hamano

diff-delta: avoid using the comma operator

2025-03-29T00:38:10Z

The comma operator is a somewhat obscure C feature that is often used by mistake and can even cause unintentional code flow. That is why the `-Wcomma` option of clang was introduced: To identify unintentional uses of the comma operator. Intentional uses include situations where one wants to avoid curly brackets around multiple statements that need to be guarded by a condition. This is the case here, as the repetitive nature of the statements is easier to see for a human reader this way. At least in my opinion. However, opinions on this differ wildly, take 10 people and you have 10 different preferences. On the Git mailing list, it seems that the consensus is to use the long form instead, so let's do just that. Suggested-by: Phillip Wood Signed-off-by: Johannes Schindelin Acked-by: Phillip Wood Signed-off-by: Junio C Hamano

global: mark code units that generate warnings with `-Wsign-compare`

2024-12-06T11:20:02Z

Mark code units that generate warnings with `-Wsign-compare`. This allows for a structured approach to get rid of all such warnings over time in a way that can be easily measured. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

diff-delta: set size out-parameter to 0 for NULL delta

2019-09-06T18:03:39Z

When we cannot generate a delta, we return NULL but leave delta_size untouched. This is generally OK, as callers rely on NULL to decide if the output is usable or not. But it can confuse compilers; in particular, gcc 9.2.1 with "-flto -O3" complains in fast-import's store_object() that delta_len may be used uninitialized. Let's change the diff-delta code to set the size explicitly to 0 for a NULL return. That silences the compiler and makes it easier to reason about the result. Reported-by: Stephan Beyer Helped-by: Junio C Hamano Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'mk/diff-delta-avoid-large-offset'

2017-09-28T05:47:56Z

The delta format used in the packfile cannot reference data at offset larger than what can be expressed in 4-byte, but the generator for the data failed to make sure the offset does not overflow. This has been corrected. * mk/diff-delta-avoid-large-offset: diff-delta: do not allow delta offset truncation

diff-delta: do not allow delta offset truncation

2017-08-11T22:25:40Z

Prevent generating delta offsets beyond 4G, as the xdelta used in the pack format cannot represent such large offset. Signed-off-by: Martin Koegler Signed-off-by: Junio C Hamano

diff-delta: fix encoding size that would not fit in "unsigned int"

2017-08-10T20:55:22Z

The current delta code produces incorrect pack objects for files > 4GB, because the size is copied from size_t field to "unsigned int" variables during the encoding process. Signed-off-by: Martin Koegler Signed-off-by: Junio C Hamano

create_delta_index: simplify condition always evaluating to true

2013-08-18T19:56:23Z

The code sequence ' (1u << i) < hsize && i < 31 ' is a multi step process, whose first step requires that 'i' is already less that 31, otherwise the result (1u << i) is undefined (and 'undef_val < hsize' can therefore be assumed to be 'false'), and so the later test i < 31 can always be optimized away as dead code ('i' is already less than 31, or the short circuit 'and' applies). So we need to get rid of that code. One way would be to exchange the order of the conditions, so the expression 'i < 31 && (1u << i) < hsize' would remove that optimized unstable code already. However when checking the previous lines in that function, we can deduce that 'hsize' must always be smaller than (1u<<31), since 506049c7df2c6 (fix >4GiB source delta assertion failure), because 'entries' is capped at an upper bound of 0xfffffffeU, so 'hsize' contains a maximum value of 0x3fffffff, which is smaller than (1u<<31), so the value of 'i' will never be larger than 31 and we can remove that condition entirely. Signed-off-by: Stefan Beller Acked-by: Nicolas Pitre Acked-by: Philip Oakley Signed-off-by: Junio C Hamano

fix >4GiB source delta assertion failure

2010-08-22T06:53:26Z

When people try insane things such as delta-compressing 4GiB files, they get this assertion: diff-delta.c:285: create_delta_index: Assertion `packed_entry - (struct index_entry *)mem == entries' failed. This happens because: 1) the 'entries' variable is an unsigned int 2) it is assigned with entries = (bufsize - 1) / RABIN_WINDOW (that itself is not a problem unless bufsize > 4G * RABIN_WINDOW) 3) the buffer is indexed from top to bottom starting at "data = buffer + entries * RABIN_WINDOW" and the multiplication here does indeed overflows, making the resulting top of the buffer much lower than expected. This makes the number of actually produced index entries smaller than what was computed initially, hence the assertion. Furthermore, the current delta encoding format cannot represent offsets into a reference buffer with more than 32 bits anyway. So let's just limit the number of entries to what the delta format can encode. Reported-by: Ilari Liusvaara Signed-off-by: Nicolas Pitre Signed-off-by: Junio C Hamano

Nicolas Pitre has a new email address

2009-09-14T09:23:36Z

Due to problems at cam.org, my nico@cam.org email address is no longer valid. From now on, nico@fluxnic.net should be used instead. Signed-off-by: Nicolas Pitre Signed-off-by: Junio C Hamano