All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Johannes Sixt <j6t@kdbg.org>
Cc: "Johannes Schindelin" <Johannes.Schindelin@gmx.de>,
	"Jeff King" <peff@peff.net>,
	git@vger.kernel.org, "René Scharfe" <l.s.r@web.de>
Subject: Re: [PATCH v4 2/5] t5000: test tar files that overflow ustar headers
Date: Thu, 14 Jul 2016 15:26:59 -0700	[thread overview]
Message-ID: <xmqqtwfronyk.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <3d71cf3a-44c7-0620-0375-fb7ecf2fac13@kdbg.org> (Johannes Sixt's message of "Thu, 14 Jul 2016 22:52:55 +0200")

Johannes Sixt <j6t@kdbg.org> 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
> unsigned long in our implementation. It may make sense to tie both
> cases to the same prerequisite.
>
> On third thought, however, I think the two requirements could diverge
> in the future. The file size case should depend on the size of
> size_t. The timestamp case may become dependent on the size of time_t
> if we decide to move timestamp handling away from unsigned long: in
> modern(!) Microsoft SDKs, time_t is 64 bits, but unsigned long is 32
> bits, in both the 32-bit and 64-bit environments!

I had the same three toughts, but this being a 'maint' material
stopped me going too deep into them.  Right now, "long being 32-bit"
is the source of all of these issues, and we would solve them on the
development track (not necessarily during this cycle) by deciding on
more appropriate types.  Timestamps may become time_t, and object
sizes may become off_t, such changes will come separately, and each
of them would need to lift "unless long is 64-bit, skip this test"
limitation and swap it with something else.


  parent reply	other threads:[~2016-07-14 22:27 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-30  9:06 [PATCH v4 0/5] friendlier handling of overflows in archive-tar Jeff King
2016-06-30  9:07 ` [PATCH v4 1/5] t9300: factor out portable "head -c" replacement Jeff King
2016-07-01  4:45   ` Eric Sunshine
2016-07-01 17:23   ` Junio C Hamano
2016-07-01 18:01     ` Jeff King
2016-06-30  9:08 ` [PATCH v4 2/5] t5000: test tar files that overflow ustar headers Jeff King
2016-07-14 15:47   ` Johannes Schindelin
2016-07-14 16:45     ` Johannes Sixt
2016-07-14 17:08       ` Junio C Hamano
2016-07-14 20:52         ` Johannes Sixt
2016-07-14 21:32           ` Jeff King
2016-07-14 22:30             ` Junio C Hamano
2016-07-14 22:38               ` Jeff King
2016-07-15 13:37                 ` Torsten Bögershausen
2016-07-15 13:46                   ` Jeff King
2016-07-14 22:26           ` Junio C Hamano [this message]
2016-07-14 18:24       ` Jeff King
2016-07-14 18:21     ` Jeff King
2016-07-14 20:00       ` Junio C Hamano
2016-07-14 20:03         ` Junio C Hamano
2016-07-14 20:14           ` Jeff King
2016-07-14 20:09         ` Junio C Hamano
2016-07-14 20:10         ` Jeff King
2016-07-14 20:22           ` Junio C Hamano
2016-07-14 20:27             ` Jeff King
2016-07-14 20:34               ` Junio C Hamano
2016-07-14 20:43                 ` [PATCH v2 0/2] ulong may only be 32-bit wide Junio C Hamano
2016-07-14 20:43                   ` [PATCH v2 1/2] t0006: skip "far in the future" test when unsigned long is not long enough Junio C Hamano
2016-07-14 20:43                   ` [PATCH v2 2/2] archive-tar: huge offset and future timestamps would not work on 32-bit Junio C Hamano
2016-07-14 22:20                     ` Jeff King
2016-07-14 22:36                       ` Junio C Hamano
2016-07-16  6:28                         ` Duy Nguyen
2016-07-15 15:10                 ` [PATCH v4 2/5] t5000: test tar files that overflow ustar headers Johannes Schindelin
2016-07-15 16:49                   ` Junio C Hamano
2016-06-30  9:09 ` [PATCH v4 3/5] archive-tar: write extended headers for file sizes >= 8GB Jeff King
2016-07-14 16:48   ` Johannes Sixt
2016-07-14 17:11     ` Junio C Hamano
2016-07-14 18:16       ` Jeff King
2016-07-15  2:59     ` Torsten Bögershausen
2016-06-30  9:09 ` [PATCH v4 4/5] archive-tar: write extended headers for far-future mtime Jeff King
2016-06-30  9:09 ` [PATCH v4 5/5] archive-tar: drop return value Jeff King
2016-06-30  9:14 ` [PATCH v4 6/5] t5000: use test_match_signal Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqtwfronyk.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=j6t@kdbg.org \
    --cc=l.s.r@web.de \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.