All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Braun <thomas.braun@virtuell-zuhause.de>
To: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Cc: "Martin Koegler" <martin.koegler@chello.at>,
	"Torsten Bögershausen" <tboegi@web.de>
Subject: mk/use-size-t-in-zlib [was: Re: What's cooking in git.git (Jan 2019, #05; Tue, 29)]
Date: Thu, 31 Jan 2019 18:59:17 +0100 (CET)	[thread overview]
Message-ID: <994568940.109648.1548957557643@ox.hosteurope.de> (raw)
In-Reply-To: <xmqqa7jj6rg7.fsf@gitster-ct.c.googlers.com>

> Junio C Hamano <gitster@pobox.com> hat am 29. Januar 2019 um 23:15 geschrieben:

[...]

> * mk/use-size-t-in-zlib (2018-10-15) 1 commit
>  - zlib.c: use size_t for size
> 
>  The wrapper to call into zlib followed our long tradition to use
>  "unsigned long" for sizes of regions in memory, which have been
>  updated to use "size_t".
> 

I've started playing around with the patch from Thorsten [1] for getting unsigned long replaced in more places so that you can commit large files on platforms like Windows there unsigned long is 32-bit even on 64-bit OSes.

And the first thing which bugs out when I do a quick test with committing a large file and fsck the repo is in zlib.c:

	if (s->z.total_out != s->total_out + bytes_produced)
		BUG("total_out mismatch");

here s->z.total_out is an unsigned long and s->total_out is size_t and this triggers the BUG message once the unsigned long wraps. There is even an FAQ entry for zlib at [2] which warns about that potential issue.

So I would think that something like

----------->8

diff --git a/zlib.c b/zlib.c
index 197a1acc7b..9cc6421eba 100644
--- a/zlib.c
+++ b/zlib.c
@@ -51,13 +51,9 @@ static void zlib_post_call(git_zstream *s)

        bytes_consumed = s->z.next_in - s->next_in;
        bytes_produced = s->z.next_out - s->next_out;
-       if (s->z.total_out != s->total_out + bytes_produced)
-               BUG("total_out mismatch");
-       if (s->z.total_in != s->total_in + bytes_consumed)
-               BUG("total_in mismatch");

-       s->total_out = s->z.total_out;
-       s->total_in = s->z.total_in;
+       s->total_out += bytes_produced;
+       s->total_in += bytes_consumed;
        s->next_in = s->z.next_in;
        s->next_out = s->z.next_out;
        s->avail_in -= bytes_consumed;

-----------8<

would make the patch [3] more complete IMHO.

Another potential issue in that patch is that the signature change in git_deflate_bound forces size to unsigned long on the call to deflateBound (for newer zlib versions) and if that conversion is not faithful this will certainly not work.

Just my 2cents I'm not vetoing anything here,
Thomas

[1]: http://public-inbox.org/git/20181120050456.16715-1-tboegi@web.de/
[2]: http://www.zlib.net/zlib_faq.html#faq32
[3]: http://public-inbox.org/git/20181012204229.11890-1-tboegi@web.de/

  parent reply	other threads:[~2019-01-31 17:59 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-29 22:15 What's cooking in git.git (Jan 2019, #05; Tue, 29) Junio C Hamano
2019-01-30 19:07 ` Jeff Hostetler
2019-01-31 17:43   ` Junio C Hamano
2019-01-31  7:43 ` Denton Liu
2019-01-31 17:49   ` Junio C Hamano
2019-01-31 17:59 ` Thomas Braun [this message]
2019-01-31 20:38   ` mk/use-size-t-in-zlib [was: Re: What's cooking in git.git (Jan 2019, #05; Tue, 29)] Torsten Bögershausen
2019-02-04 21:13 ` What's cooking in git.git (Jan 2019, #05; Tue, 29) Thomas Gummerer
2019-02-04 21:30   ` Junio C Hamano
2019-02-05 20:42     ` Thomas Gummerer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=994568940.109648.1548957557643@ox.hosteurope.de \
    --to=thomas.braun@virtuell-zuhause.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=martin.koegler@chello.at \
    --cc=tboegi@web.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.