Re: [PATCH 0/5] Number truncation with 4+ GB files on 32-bit systems
- From
Duy Nguyen <pclouds@gmail.com>
- Date
- Jul 13, 2016, 06:01 UTC
- Message-ID
- <CACsJy8CXg_x_4GRe88yUBYFm-_1=REAox=wK5yzu4W7Mf2qwgQ@mail.gmail.com>
- In-Reply-To
- <xmqq60sa4mnv.fsf@gitster.mtv.corp.google.com>
On Tue, Jul 12, 2016 at 10:38 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 16 quoted lines
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes: > >> Since I now could reproduce the problem that Christoph showed, I >> decided to send the good patches out. To sum up, we use "unsigned >> long" in some places related to file size. On 32-bit systems, it's >> limited to 32 bits even though the system can handle files larger than >> that (off_t is 64-bit). This fixes it. >> >> clang -Wshorten-64-to-32 is very helpful to spot these problems. I >> have a couple more patches to clean all these warnings, but some need >> more code study to see what is the right way to do. >> >> Most of the rest seems harmless, except for the local variable "size" >> in builtin/pack-objects.c:write_one(). I might send 6/5 for that one. > > With 1-7/5 it appears t1050 is broken?
Oops, sorry I focused on testing big repos and forgot the test suite. But hehe.. it's a good thing. That test was added by 735efde, where fsck could keep on going after failing to inflate some blobs (instead of hitting malloc failure and abort). Now it's even better, fsck passes. I'll fix that up and resend with your squashes in.
-- Duy