Re: [PATCH v2 07/12] packfile, git-zlib: widen `use_pack()` and zstream avail fields to `size_t`

[Junio C Hamano <gitster@pobox.com>]

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
writes:

> diff --git a/git-zlib.h b/git-zlib.h
> index 44380e8ad3..0b24b15bd0 100644
> --- a/git-zlib.h
> +++ b/git-zlib.h
> @@ -5,8 +5,8 @@
>  
>  typedef struct git_zstream {
>  	struct z_stream_s z;
> -	unsigned long avail_in;
> -	unsigned long avail_out;
> +	size_t avail_in;
> +	size_t avail_out;
>  	size_t total_in;
>  	size_t total_out;
>  	unsigned char *next_in;

We have these size_t which means we can use a buffer larger than 4GB
where size_t is larger than 32-bit ulong.  But these are sizes of a
single contiguous buffer, so I think that is why the log message
mentioned that this is more of type consistency than being able to
handle larger data (I do not think people feed >4GB contiguious
buffer in one go in practice).

 - zlib_buf_cap() is still "unsigned long", and zlib_pre_call()
   feeds these potentially wider values to it.  Is it possible that
   we trigger truncation before the avail_in/avail_out is compared
   with ZLIB_BUF_MAX in the zlib_buf_cap() function?

 - unpack_object_header_buffer() still takes "unsigned long" length;
   builtin/pack-objects.c:oe_get_size_slow() passes size_t avail to
   unpack_object_header_buffer().  This comes from use_pack(), so it
   is a relatively small value stored in wider size_t but I am unsure
   if your static checker would not flag for potential truncation?