From: Erik Faye-Lund Date: Mon, 13 Jun 2011 11:17:00 GMT Subject: Re: [PATCH 6/6] zlib: zlib can only process 4GB at a time Message-ID: In-Reply-To: <7v4o3uspiy.fsf@alter.siamese.dyndns.org> On Sun, Jun 12, 2011 at 11:33 PM, Junio C Hamano wrote: > Erik Faye-Lund writes: > >> On Fri, Jun 10, 2011 at 10:15 PM, Junio C Hamano 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.