[PATCH 0/6] zlib only processes 4GB at a time

This is a re-roll from yesterday's series, taking a very different approach. Instead of fixing call sites one by one, the goal is to define our own API that can give an illusion to the callers that they can feed and receive data whose size can fit within "unsigned long", so that they can set up the avail_in field of z_stream (now git_zstream) to the total size, and expect it to fall down to zero when everything is consumed by the library (vice versa for avail_out).

The first 5 patches clean up the existing callers that directly call into zlib to call git_inflate and git_deflate wrappers.

Patch 6 introduces git_zstream that is a thin wrapper around z_stream, but barfs when the caller gives a buffer larger than 4GB that would fit the underlying zlib calling convention.

The next step would be to tweak zlib_post_call(), git_inflate() and git_deflate() functions to internally loop and call underlying inflate() and deflate() when the incoming buffers are larger than 4GB, but that part is not done in this series (yet).

Junio C Hamano (6):
  zlib: refactor error message formatter
  zlib: wrap remaining calls to direct inflate/inflateEnd
  zlib: wrap inflateInit2 used to accept only for gzip format
  zlib: wrap deflate side of the API
  zlib: wrap deflateBound() too
  zlib: zlib can only process 4GB at a time

 archive-zip.c            |   10 +-
 builtin/apply.c          |    2 +-
 builtin/index-pack.c     |   12 ++--
 builtin/pack-objects.c   |   18 ++--
 builtin/unpack-objects.c |    2 +-
 cache.h                  |   30 +++++--
 diff.c                   |   10 +-
 fast-import.c            |   30 +++---
 http-backend.c           |   11 +--
 http-push.c              |   16 ++--
 http.h                   |    2 +-
 pack-check.c             |    4 +-
 remote-curl.c            |   14 +--
 sha1_file.c              |   28 +++---
 zlib.c                   |  218 +++++++++++++++++++++++++++++++++++++++-------
 15 files changed, 283 insertions(+), 124 deletions(-)