• Junio C Hamano's avatar
    zlib: zlib can only process 4GB at a time · ef49a7a0
    Junio C Hamano authored
    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: default avatarJunio C Hamano <gitster@pobox.com>
    ef49a7a0
zlib.c 4.63 KB