From: Junio C Hamano <gitster@pobox.com>
To: "darcy via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, darcy <acednes@gmail.com>
Subject: Re: [PATCH v3] date: detect underflow/overflow when parsing dates with timezone offset
Date: Thu, 13 Jun 2024 18:20:53 -0700 [thread overview]
Message-ID: <xmqqwmmsiakq.fsf@gitster.g> (raw)
In-Reply-To: <xmqqcyorcldv.fsf@gitster.g> (Junio C. Hamano's message of "Sat, 08 Jun 2024 11:58:04 -0700")
Junio C Hamano <gitster@pobox.com> writes:
> The CI build on Windows tells me that my worry was warranted.
>
> https://github.com/git/git/actions/runs/9424299208/job/25964281907#step:4:643
>
> (GitHub seems to show the breakage details only to those who are
> logged in, so you'd need to be logged in to visit that link)
So here is what I accumulated in SQUASH??? patches on top of your
topic while waiting for an updated version to unbreak the CI.
* The "end of git time" timestamp does not fit in time_t on 32-bit
systems, so I updated it to use timestamp_t at least for now.
* t0006 has two tests that use TIME_IS_64BIT,TIME_T_IS_64BIT
prerequisites; I introduced HAVE_64BIT_TIME to simplify them.
* nobody passes $4 to check_parse to tell it to expect a failure,
so I removed it. It always expects success.
* check_parse now honors a global variable REQUIRE_64BIT_TIME that
is used as the prerequisite to run its test_expect_success; the
"near the end of git time" tests you added use the mechanism to
pass HAVE_64BIT_TIME prerequisite.
The last one is a bit questionable, as it only "punts" on 32-bit
systems, instead of making sure we get the expected error messages.
I think it is OK to punt here and have a separate test that checks
timestamp around year 2040 for that condition.
date.c | 2 +-
t/t0006-date.sh | 20 ++++++++++++++------
2 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/date.c b/date.c
index 95776c8a92..bee9fe8f10 100644
--- a/date.c
+++ b/date.c
@@ -870,7 +870,7 @@ static int match_object_header_date(const char *date, timestamp_t *timestamp, in
/* timestamp of 2099-12-31T23:59:59Z, including 32 leap days */
-static const time_t timestamp_max = ((2100L - 1970) * 365 + 32) * 24 * 60 * 60 - 1;
+static const timestamp_t timestamp_max = (((timestamp_t)2100 - 1970) * 365 + 32) * 24 * 60 * 60 - 1;
/* Gr. strptime is crap for this; it doesn't have a way to require RFC2822
(i.e. English) day/month names, and it doesn't work correctly with %z. */
diff --git a/t/t0006-date.sh b/t/t0006-date.sh
index e8fdf361ad..fd373e1b39 100755
--- a/t/t0006-date.sh
+++ b/t/t0006-date.sh
@@ -8,6 +8,11 @@ TEST_PASSES_SANITIZE_LEAK=true
# arbitrary reference time: 2009-08-30 19:20:00
GIT_TEST_DATE_NOW=1251660000; export GIT_TEST_DATE_NOW
+if test_have_prereq TIME_IS_64BIT,TIME_T_IS_64BIT
+then
+ test_set_prereq HAVE_64BIT_TIME
+fi
+
check_relative() {
t=$(($GIT_TEST_DATE_NOW - $1))
echo "$t -> $2" >expect
@@ -80,14 +85,15 @@ check_show raw "$TIME" '1466000000 -0200'
# arbitrary time absurdly far in the future
FUTURE="5758122296 -0400"
-check_show iso "$FUTURE" "2152-06-19 18:24:56 -0400" TIME_IS_64BIT,TIME_T_IS_64BIT
-check_show iso-local "$FUTURE" "2152-06-19 22:24:56 +0000" TIME_IS_64BIT,TIME_T_IS_64BIT
+check_show iso "$FUTURE" "2152-06-19 18:24:56 -0400" HAVE_64BIT_TIME
+check_show iso-local "$FUTURE" "2152-06-19 22:24:56 +0000" HAVE_64BIT_TIME
-check_parse() {
+REQUIRE_64BIT_TIME=
+check_parse () {
echo "$1 -> $2" >expect
- test_expect_${4:-success} "parse date ($1${3:+ TZ=$3})" "
- TZ=${3:-$TZ} test-tool date parse '$1' >actual &&
- test_cmp expect actual
+ test_expect_success $REQUIRE_64BIT_TIME "parse date ($1${3:+ TZ=$3}) -> $2" "
+ TZ=${3:-$TZ} test-tool date parse '$1' >actual &&
+ test_cmp expect actual
"
}
@@ -133,6 +139,7 @@ check_parse '1969-12-31 23:59:59 Z' bad
check_parse '1969-12-31 23:59:59 +11' bad
check_parse '1969-12-31 23:59:59 -11' bad
+REQUIRE_64BIT_TIME=HAVE_64BIT_TIME
check_parse '2099-12-31 23:59:59' '2099-12-31 23:59:59 +0000'
check_parse '2099-12-31 23:59:59 +00' '2099-12-31 23:59:59 +0000'
check_parse '2099-12-31 23:59:59 Z' '2099-12-31 23:59:59 +0000'
@@ -147,6 +154,7 @@ check_parse '2100-00-00 00:00:00 +00' bad
check_parse '2100-00-00 00:00:00 Z' bad
check_parse '2100-00-00 00:00:00 -11' bad
check_parse '2100-00-00 00:00:00 +11' bad
+REQUIRE_64BIT_TIME=
check_approxidate() {
echo "$1 -> $2 +0000" >expect
next prev parent reply other threads:[~2024-06-14 1:20 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-27 9:17 [PATCH] fix: prevent date underflow when using positive timezone offset darcy via GitGitGadget
2024-05-28 14:05 ` Patrick Steinhardt
2024-05-28 14:49 ` Phillip Wood
2024-05-28 17:06 ` Junio C Hamano
2024-06-02 23:06 ` [PATCH v2] date: detect underflow when parsing dates with " darcy via GitGitGadget
2024-06-03 11:13 ` Junio C Hamano
2024-06-03 11:44 ` darcy
2024-06-03 14:13 ` Phillip Wood
2024-06-04 8:48 ` darcy
2024-06-04 9:33 ` Jeff King
2024-06-05 6:52 ` darcy
2024-06-05 13:10 ` Phillip Wood
2024-06-05 17:27 ` Junio C Hamano
2024-06-06 4:56 ` darcy
2024-06-07 0:17 ` [PATCH v3] date: detect underflow/overflow when parsing dates with " darcy via GitGitGadget
2024-06-07 17:40 ` Junio C Hamano
2024-06-08 18:58 ` Junio C Hamano
2024-06-14 1:20 ` Junio C Hamano [this message]
2024-06-15 11:47 ` Karthik Nayak
2024-06-11 23:30 ` Junio C Hamano
2024-06-11 23:49 ` rsbecker
2024-06-11 23:52 ` Junio C Hamano
2024-06-25 23:12 ` [PATCH v4 0/2] Darcy's "date underflow fix" topic, final reroll Junio C Hamano
2024-06-25 23:12 ` [PATCH v4 1/2] t0006: simplify prerequisites Junio C Hamano
2024-06-25 23:30 ` Eric Sunshine
2024-06-26 0:04 ` Junio C Hamano
2024-06-25 23:12 ` [PATCH v4 2/2] date: detect underflow/overflow when parsing dates with timezone offset Junio C Hamano
2024-06-26 15:21 ` [PATCH v4 0/2] Darcy's "date underflow fix" topic, final reroll Phillip Wood
2024-06-26 18:32 ` Junio C Hamano
2024-06-12 9:07 ` [PATCH v3] date: detect underflow/overflow when parsing dates with timezone offset Phillip Wood
2024-06-12 9:49 ` Karthik Nayak
2024-06-13 13:31 ` Phillip Wood
2024-06-13 16:16 ` Junio C Hamano
2024-06-14 20:09 ` Karthik Nayak
2024-06-14 21:02 ` Junio C Hamano
2024-06-15 11:49 ` Karthik Nayak
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=xmqqwmmsiakq.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=acednes@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
/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.