Re: [PATCH 6/6] zlib: zlib can only process 4GB at a time

[Erik Faye-Lund <kusmabite@gmail.com>]

On Sun, Jun 12, 2011 at 11:33 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Erik Faye-Lund <kusmabite@gmail.com> writes:
>
>> On Fri, Jun 10, 2011 at 10:15 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> 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.
>>
>> shouldn't this be "size_t" instead of "unsigned long"?
>
> No, this must be unsigned long as that is the internal type we use.

I'm not sure I even understand what you mean here. "unsigned long" is
the only choice because it's the type we use? That's sounds pretty
close to tautology to my ears.

Looking a bit more at the code, it seems that we currently use
"unsigned long" a lot of places where "size_t" should have been used.
And this series is about changing places where "unsigned int" is being
used instead of "unsigned long". This sounds backwards to me;
shouldn't all code that deals with sizes (both the ones that are
"unsigned int" AND the ones that are "unsigned long") be changed to
size_t instead?

> Implementation of git on 32-bit platforms has always been limited to 4GB
> from day one. This topic is not about changing it.

As Matthieu pointed out, my comment wasn't about 32-bit systems;
"unsigned long" is 32-bit even on 64-bit versions on Windows. I
believe TortoiseGit builds Git for Windows as 64-bit, so AFAIK this
would still be a problem for them.