> Torsten Bögershausen <tboegi@xxxxxx> hat am 17. März 2017 um 06:29
> geschrieben:
>
>
> On 15/03/17 22:29, Junio C Hamano wrote:
> > Torsten Bögershausen <tboegi@xxxxxx> writes:
> >
> >> The real "show stopper" is at the end.
> >> ...
> >>
> >> ==========================
> >> And it seams as if zlib is the limitation here.
> >> Unless we include the zlib source code into Git and redefine uLong,
> >> is there a nice way around this:
> >> ===========================
> >>
> >>
> >> /usr/include/zconf.h:# define uLong z_uLong
> >> /usr/include/zconf.h:# define uLongf z_uLongf
> >> /usr/include/zconf.h:typedef unsigned long uLong; /* 32 bits or more */
> >> /usr/include/zconf.h:typedef uLong FAR uLongf;
> > Hmph. Would ef49a7a0 ("zlib: zlib can only process 4GB at a time",
> > 2011-06-10) and e01503b5 ("zlib: allow feeding more than 4GB in one
> > go", 2011-06-10) help us here, though?
> >
> That is good news.
> I tried to replace all "unsigned long" with size_t and got that compiling
> without warnings under Windows 64 bit.
>
> Compiling this on a 32 bit Linux gave lots of warnings..
>
> Converting all unsigned long into is probably an overkill.
> Some may stay, some may be converted into off_t, and some size_t.
>
> Does anybody wants to pick this up?
I'd be interested, altough I can't promise to get it done in the near future.