git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Erik Faye-Lund <kusmabite@gmail.com>
Date
Jun 13, 2011, 11:17 UTC
Message-ID
<BANLkTi=sT_LxRaJSM3Cj-QkSwqGan29K7A@mail.gmail.com>
In-Reply-To
<7v4o3uspiy.fsf@alter.siamese.dyndns.org>
On Sun, Jun 12, 2011 at 11:33 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 10 quoted lines
> 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.

Previous: Matthieu MoyNext: Jonathan Nieder
Message 13 of 16 in “zlib only processes 4GB at a time”
  1. 0/6 zlib only processes 4GB at a timeJunio C Hamano, Jun 10, 2011
  2. 1/6 zlib: refactor error message formatterJunio C Hamano, Jun 10, 2011
  3. 2/6 zlib: wrap remaining calls to direct inflate/inflateEndJunio C Hamano, Jun 10, 2011
  4. 3/6 zlib: wrap inflateInit2 used to accept only for gzip formatJunio C Hamano, Jun 10, 2011
  5. 4/6 zlib: wrap deflate side of the APIJunio C Hamano, Jun 10, 2011
  6. Thiago FarinaJun 10, 2011
  7. Junio C HamanoJun 10, 2011
  8. 5/6 zlib: wrap deflateBound() tooJunio C Hamano, Jun 10, 2011
  9. 6/6 zlib: zlib can only process 4GB at a timeJunio C Hamano, Jun 10, 2011
  10. Erik Faye-LundJun 12, 2011
  11. Junio C HamanoJun 12, 2011
  12. Matthieu MoyJun 12, 2011
  13. Erik Faye-LundJun 13, 2011
  14. Jonathan NiederJun 13, 2011
  15. Junio C HamanoJun 13, 2011
  16. 7/6 zlib: allow feeding more than 4GB in one goJunio C Hamano, Jun 10, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.