delta/git.git/pack-check.c, branch wd/userdiff-css

convert trivial cases to ALLOC_ARRAY

2016-02-22T22:51:09+00:00

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

verify_pack: do not ignore return value of verification function

2015-12-01T23:19:35+00:00

In verify_pack, a caller-supplied verification function is called.
The function returns an int.  If that return value is non-zero,
verify_pack should fail.

The only caller of verify_pack is in builtin/fsck.c, whose verify_fn
returns a meaningful error code (which was then ignored).  Now, fsck
might return a different error code (with more detail).  This would
happen in the unlikely event that a commit or tree that is a valid git
object but not a valid instance of its type gets into a pack.

Signed-off-by: David Turner 
Signed-off-by: Jeff King

fsck: print progress

2011-11-07T04:31:28+00:00

fsck is usually a long process and it would be nice if it prints
progress from time to time.

Progress meter is not printed when --verbose is given because
--verbose prints a lot, there's no need for "alive" indicator.
Progress meter may provide "% complete" information but it would
be lost anyway in the flood of text.

Signed-off-by: Nguyễn Thái Ngọc Duy 
Signed-off-by: Junio C Hamano

fsck: avoid reading every object twice

2011-11-07T04:31:28+00:00

During verify_pack() all objects are read for SHA-1 check. Then
fsck_sha1() is called on every object, which read the object again
(fsck_sha1 -> parse_object -> read_sha1_file).

Avoid reading an object twice, do fsck_sha1 while we have an object
uncompressed data in verify_pack.

On git.git, with this patch I got:

$ /usr/bin/time ./git fsck >/dev/null
98.97user 0.90system 1:40.01elapsed 99%CPU (0avgtext+0avgdata 616624maxresident)k
0inputs+0outputs (0major+194186minor)pagefaults 0swaps

Without it:

$ /usr/bin/time ./git fsck >/dev/null
231.23user 2.35system 3:53.82elapsed 99%CPU (0avgtext+0avgdata 636688maxresident)k
0inputs+0outputs (0major+461629minor)pagefaults 0swaps

Signed-off-by: Nguyễn Thái Ngọc Duy 
Signed-off-by: Junio C Hamano

verify_packfile(): check as many object as possible in a pack

2011-11-07T04:31:28+00:00

verify_packfile() checks for whole pack integerity first, then each
object individually. Once we get past whole pack check, we can
identify all objects in the pack. If there's an error with one object,
we should continue to check the next objects to salvage as many
objects as possible instead of stopping the process.

Signed-off-by: Nguyễn Thái Ngọc Duy 
Signed-off-by: Junio C Hamano

zlib: zlib can only process 4GB at a time

2011-06-10T18:52:15+00:00

The size of objects we read from the repository and data we try to put
into the repository are represented in "unsigned long", so that on larger
architectures we can handle objects that weigh more than 4GB.

But the interface defined in zlib.h to communicate with inflate/deflate
limits avail_in (how many bytes of input are we calling zlib with) and
avail_out (how many bytes of output from zlib are we ready to accept)
fields effectively to 4GB by defining their type to be uInt.

In many places in our code, we allocate a large buffer (e.g. mmap'ing a
large loose object file) and tell zlib its size by assigning the size to
avail_in field of the stream, but that will truncate the high octets of
the real size. The worst part of this story is that we often pass around
z_stream (the state object used by zlib) to keep track of the number of
used bytes in input/output buffer by inspecting these two fields, which
practically limits our callchain to the same 4GB limit.

Wrap z_stream in another structure git_zstream that can express avail_in
and avail_out in unsigned long. For now, just die() when the caller gives
a size that cannot be given to a single zlib call. In later patches in the
series, we would make git_inflate() and git_deflate() internally loop to
give callers an illusion that our "improved" version of zlib interface can
operate on a buffer larger than 4GB in one go.

Signed-off-by: Junio C Hamano

sparse: Fix errors and silence warnings

2011-04-03T17:14:53+00:00

 * load_file() returns a void pointer but is using 0 for the return
   value

 * builtin/receive-pack.c forgot to include builtin.h

 * packet_trace_prefix can be marked static

 * ll_merge takes a pointer for its last argument, not an int

 * crc32 expects a pointer as the second argument but Z_NULL is defined
   to be 0 (see 38f4d13 sparse fix: Using plain integer as NULL pointer,
   2006-11-18 for more info)

Signed-off-by: Stephen Boyd 
Signed-off-by: Junio C Hamano

standardize brace placement in struct definitions

2011-03-16T19:49:02+00:00

In a struct definitions, unlike functions, the prevailing style is for
the opening brace to go on the same line as the struct name, like so:

 struct foo {
	int bar;
	char *baz;
 };

Indeed, grepping for 'struct [a-z_]* {$' yields about 5 times as many
matches as 'struct [a-z_]*$'.

Linus sayeth:

 Heretic people all over the world have claimed that this inconsistency
 is ...  well ...  inconsistent, but all right-thinking people know that
 (a) K&R are _right_ and (b) K&R are right.

Signed-off-by: Jonathan Nieder 
Signed-off-by: Junio C Hamano

Typos in code comments, an error message, documentation

2010-08-22T20:25:08+00:00

Signed-off-by: Ralf Wildenhues 
Signed-off-by: Junio C Hamano

Extract verify_pack_index for reuse from verify_pack

2010-04-20T00:56:13+00:00

The dumb HTTP transport should verify an index is completely valid
before trying to use it.  That requires checking the header/footer
but also checking the complete content SHA-1.  All of this logic is
already in the front half of verify_pack, so pull it out into a new
function that can be reused.

Signed-off-by: Shawn O. Pearce 
Signed-off-by: Junio C Hamano