user/sven/git.git/diff-delta.c, branch v2.26.0-rc2

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

fix style of a few comments in diff-delta.c

2007-12-18T23:22:28Z

Signed-off-by: Nicolas Pitre Signed-off-by: Junio C Hamano

Fix segfault in diff-delta.c when FLEX_ARRAY is 1

2007-12-18T05:59:26Z

aka don't do pointer arithmetics on structs that have a FLEX_ARRAY member, or you'll end up believing your array is 1 cell off its real address. Signed-off-by: Pierre Habouzit Signed-off-by: Junio C Hamano

diff-delta.c: Rationalize culling of hash buckets

2007-09-10T00:16:49Z

The previous hash bucket culling resulted in a somewhat unpredictable number of hash bucket entries in the order of magnitude of HASH_LIMIT. Replace this with a Bresenham-like algorithm leaving us with exactly HASH_LIMIT entries by uniform culling. Signed-off-by: David Kastrup Acked-by: Nicolas Pitre Signed-off-by: Junio C Hamano