Re: [PATCH v2 1/1] zlib.c: use size_t for size

2018-10-14 Thread Torsten Bögershausen
On 15.10.18 06:22, Junio C Hamano wrote: > Ramsay Jones writes: > >>> >>> For the record, I am not opposed to including the comment _and_ using >>> xsize_t() to do the cast, giving us an assertion that the comment is >>> correct. >> >> Heh, I haven't found any enthusiasm tonight. Let's see if the

Re: [PATCH v2 1/1] zlib.c: use size_t for size

2018-10-14 Thread Junio C Hamano
Ramsay Jones writes: >> >> For the record, I am not opposed to including the comment _and_ using >> xsize_t() to do the cast, giving us an assertion that the comment is >> correct. > > Heh, I haven't found any enthusiasm tonight. Let's see if there > are any more comments/opinions. OK, in the m

Re: [PATCH v2 1/1] zlib.c: use size_t for size

2018-10-14 Thread Ramsay Jones
On 15/10/18 01:01, Jeff King wrote: > On Sun, Oct 14, 2018 at 04:03:48PM +0100, Ramsay Jones wrote: > >>> So I kind of wonder if a comment would be better than xsize_t here. >>> Something like: >>> >>> if (avail > len) { >>> /* >>> * This can never truncate because we know that len i

Re: [PATCH v2 1/1] zlib.c: use size_t for size

2018-10-14 Thread Jeff King
On Sun, Oct 14, 2018 at 04:03:48PM +0100, Ramsay Jones wrote: > > So I kind of wonder if a comment would be better than xsize_t here. > > Something like: > > > > if (avail > len) { > > /* > > * This can never truncate because we know that len is smaller > > * than avail, which is

Re: [PATCH v2 1/1] zlib.c: use size_t for size

2018-10-14 Thread Ramsay Jones
On 14/10/18 03:52, Jeff King wrote: > On Sun, Oct 14, 2018 at 03:16:36AM +0100, Ramsay Jones wrote: > >> diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c >> index b059b86aee..3b5f2c38b3 100644 >> --- a/builtin/pack-objects.c >> +++ b/builtin/pack-objects.c >> @@ -269,12 +269,12 @@ s

Re: [PATCH v2 1/1] zlib.c: use size_t for size

2018-10-13 Thread Jeff King
On Sun, Oct 14, 2018 at 03:16:36AM +0100, Ramsay Jones wrote: > diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c > index b059b86aee..3b5f2c38b3 100644 > --- a/builtin/pack-objects.c > +++ b/builtin/pack-objects.c > @@ -269,12 +269,12 @@ static void copy_pack_data(struct hashfile *f, >

Re: [PATCH v2 1/1] zlib.c: use size_t for size

2018-10-13 Thread Ramsay Jones
On 14/10/18 03:16, Ramsay Jones wrote: > > > On 13/10/18 06:00, Torsten Bögershausen wrote: >> [] >>> Neither v1 nor v2 of this patch compiles on 32 bit Linux; see >>> >>> https://travis-ci.org/git/git/jobs/440514375#L628 >>> >>> The fixup patch below makes it compile on 32 bit and the test

Re: [PATCH v2 1/1] zlib.c: use size_t for size

2018-10-13 Thread Ramsay Jones
On 13/10/18 06:00, Torsten Bögershausen wrote: > [] >> Neither v1 nor v2 of this patch compiles on 32 bit Linux; see >> >> https://travis-ci.org/git/git/jobs/440514375#L628 >> >> The fixup patch below makes it compile on 32 bit and the test suite >> passes as well, but I didn't thoroughly revi

Re: [PATCH v2 1/1] zlib.c: use size_t for size

2018-10-12 Thread Torsten Bögershausen
[] > Neither v1 nor v2 of this patch compiles on 32 bit Linux; see > > https://travis-ci.org/git/git/jobs/440514375#L628 > > The fixup patch below makes it compile on 32 bit and the test suite > passes as well, but I didn't thoroughly review the changes; I only > wanted to get 'pu' build again.

Re: [PATCH v2 1/1] zlib.c: use size_t for size

2018-10-12 Thread SZEDER Gábor
On Fri, Oct 12, 2018 at 10:42:29PM +0200, tbo...@web.de wrote: > From: Martin Koegler > > Signed-off-by: Martin Koegler > Signed-off-by: Junio C Hamano > Signed-off-by: Torsten Bögershausen > --- > > After doing a review, I decided to send the result as a patch. > In general, the changes from

[PATCH v2 1/1] zlib.c: use size_t for size

2018-10-12 Thread tboegi
From: Martin Koegler Signed-off-by: Martin Koegler Signed-off-by: Junio C Hamano Signed-off-by: Torsten Bögershausen --- After doing a review, I decided to send the result as a patch. In general, the changes from off_t to size_t seem to be not really motivated. But if they are, they could and