Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

Johannes Schindelin writes: > So what are your plans with 2.9.2? I ask because I do not want to engineer > a 2.9.1 release just to see that 2.9.2 is out and having to spend the same > amount of time for another release ;-) Essentially unchanged from what I said in

Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

Hi Junio, On Thu, 14 Jul 2016, Junio C Hamano wrote: > Jeff King writes: > > > Yeah, that is what I was trying to get at, but you stated it much more > > clearly. LONG_IS_64BIT is good. I wonder if the "git version > > --build-options" should be "sizeof-long", too. It's shorter,

Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

On Fri, Jul 15, 2016 at 03:37:32PM +0200, Torsten Bögershausen wrote: > > So off_t is probably better. We do need to be careful, though, when > > allocating objects. E.g., this: > > > > off_t size; > > struct git_istream *stream; > > void *buf; > > > > stream = open_istream(sha1, , ,

Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

On 07/15/2016 12:38 AM, Jeff King wrote: On Thu, Jul 14, 2016 at 03:30:58PM -0700, Junio C Hamano wrote: If we move to time_t everywhere, I think we'll need an extra TIME_T_IS_64BIT, but we can cross that bridge when we come to it. Likewise I think we'll need SIZE_T_IS_64BIT eventually (for

Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

On Thu, Jul 14, 2016 at 03:30:58PM -0700, Junio C Hamano wrote: > > If we move to time_t everywhere, I think we'll need an extra > > TIME_T_IS_64BIT, but we can cross that bridge when we come to it. > > > > Likewise I think we'll need SIZE_T_IS_64BIT eventually (for real 32-bit > > systems; LLP64

Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

Jeff King writes: > If we move to time_t everywhere, I think we'll need an extra > TIME_T_IS_64BIT, but we can cross that bridge when we come to it. > > Likewise I think we'll need SIZE_T_IS_64BIT eventually (for real 32-bit > systems; LLP64 systems like Windows will then be able

Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

Johannes Sixt writes: > My first thought was that this is not warranted because t0006 is about > commit time stamps, but the huge-tar breakage is file sizes, and the > cases should be treated differently. > > But on second thought, under the hood, both boil down to the size of >

Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

On Thu, Jul 14, 2016 at 10:52:55PM +0200, Johannes Sixt wrote: > > Dscho? I'll revert the merge of 'js/t0006-for-v2.9.2' out of > > 'next' so that we can replace it with your newer version, but it > > needs to be massaged to lose the strong linkage with "time", as > > it is no longer "is our

Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

Am 14.07.2016 um 19:08 schrieb Junio C Hamano: Johannes Sixt writes: Am 14.07.2016 um 17:47 schrieb Johannes Schindelin: On Thu, 30 Jun 2016, Jeff King wrote: The ustar format only has room for 11 (or 12, depending on some implementations) octal digits for the size and mtime

Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

Jeff King writes: > Yeah, that is what I was trying to get at, but you stated it much more > clearly. LONG_IS_64BIT is good. I wonder if the "git version > --build-options" should be "sizeof-long", too. It's shorter, and > indicates our assumption that we are talking about all

Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

On Thu, Jul 14, 2016 at 01:22:01PM -0700, Junio C Hamano wrote: > > Also, shouldn't it be checking against 0x? > > Correct. Somehow I thought I was checking with LONG_MAX. Will correct. > > > An easier check would be "sizeof()", but I guess we can't use that in a > > preprocessor

Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

Jeff King writes: >> +#if ULONG_MAX == 0x7FFF >> +#define USTAR_MAX_SIZE ULONG_MAX >> +#define USTAR_MAX_MTIME ULONG_MAX >> +#else >> #define USTAR_MAX_SIZE 0777UL >> #define USTAR_MAX_MTIME 0777UL >> +#endif >> >> /* writes out the whole block, but only

Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

On Thu, Jul 14, 2016 at 01:03:35PM -0700, Junio C Hamano wrote: > Junio C Hamano writes: > > > OK, how about this on top of a replacement for js/t0006-for-v2.9.2 > > that I'll send out as a reply to this message? > > which is this one, which is largely from your

Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

On Thu, Jul 14, 2016 at 01:00:08PM -0700, Junio C Hamano wrote: > > There's tons of discussion in: > > > > http://thread.gmane.org/gmane.comp.version-control.git/297409 > > > > but frankly it is not worth your time to read it. These tests are about > > overflowing the tar limits, which can only

Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

Junio C Hamano writes: > OK, how about this on top of a replacement for js/t0006-for-v2.9.2 > that I'll send out as a reply to this message? I won't repeat the patch body, but I had to write a log message, so here is what I tentatively committed (not queued yet). Subject:

Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

Junio C Hamano writes: > OK, how about this on top of a replacement for js/t0006-for-v2.9.2 > that I'll send out as a reply to this message? which is this one, which is largely from your $gmane/299310. -- >8 -- From: Jeff King Date: Mon, 11 Jul 2016 19:54:18

Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

Jeff King writes: > On Thu, Jul 14, 2016 at 05:47:41PM +0200, Johannes Schindelin wrote: > >> On Thu, 30 Jun 2016, Jeff King wrote: >> >> > The ustar format only has room for 11 (or 12, depending on >> > some implementations) octal digits for the size and mtime of >> > each file.

Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

On Thu, Jul 14, 2016 at 06:45:47PM +0200, Johannes Sixt wrote: > Am 14.07.2016 um 17:47 schrieb Johannes Schindelin: > > On Thu, 30 Jun 2016, Jeff King wrote: > > > The ustar format only has room for 11 (or 12, depending on > > > some implementations) octal digits for the size and mtime of > > >

Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

On Thu, Jul 14, 2016 at 05:47:41PM +0200, Johannes Schindelin wrote: > On Thu, 30 Jun 2016, Jeff King wrote: > > > The ustar format only has room for 11 (or 12, depending on > > some implementations) octal digits for the size and mtime of > > each file. For values larger than this, we have to

Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

Johannes Sixt writes: > Am 14.07.2016 um 17:47 schrieb Johannes Schindelin: >> On Thu, 30 Jun 2016, Jeff King wrote: >>> The ustar format only has room for 11 (or 12, depending on >>> some implementations) octal digits for the size and mtime of >>> each file. For values larger

Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

Am 14.07.2016 um 17:47 schrieb Johannes Schindelin: On Thu, 30 Jun 2016, Jeff King wrote: The ustar format only has room for 11 (or 12, depending on some implementations) octal digits for the size and mtime of each file. For values larger than this, we have to add pax extended headers to

Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers

Hi Peff, sorry for the very, very late reply. On Thu, 30 Jun 2016, Jeff King wrote: > The ustar format only has room for 11 (or 12, depending on > some implementations) octal digits for the size and mtime of > each file. For values larger than this, we have to add pax > extended headers to