All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org,  Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: [PATCH 5/5] date: avoid overflow in approxidate relative-time multiplication
Date: Wed, 14 Oct 2026 14:44:51 -0700	[thread overview]
Message-ID: <xmqq4ieoq7n0.fsf@gitster.g> (raw)
In-Reply-To: <a4e602b9e726081aaaf73c627548b823a4d35477.1791958171.git.gitgitgadget@gmail.com> (Johannes Schindelin via GitGitGadget's message of "Wed, 14 Oct 2026 06:09:31 +0000")

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
writes:

> On platforms where `time_t` is unsigned (and where the pre-processor
> allows us to determine this fact), reject counts that are too large and
> report a parse error. Narrowing them first could otherwise produce
> negative or truncated values that become bogus offsets. Leave signed
> `time_t` count parsing unchanged.

Does this mean that "git log -p" in a project that were made on
reasonably sized platforms and then cloned to my box may cause the
history traversal to stop with an error when a commit has author or
committer timestamp that would not fit the time_t on my box?

It would have been horrible regression than showing the entire
history with patches with bogus timestamp if it were the case.

But I do not think that is what happens.  approxidate_careful() is
only used to parse input by local user (e.g., "git commit
--date="...", "git log @{...}"), and the changes in this patch would
not affect behaviours of other uses of timestamps, so we are safe.

> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>  date.c | 26 ++++++++++++++++++++++++--
>  1 file changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/date.c b/date.c
> index 014065b419..0d65804d2f 100644
> --- a/date.c
> +++ b/date.c
> @@ -1298,7 +1298,18 @@ static const char *approxidate_alpha(const char *date, struct tm *tm, struct tm
>  	while (tl->type) {
>  		size_t len = strlen(tl->type);
>  		if (match_string(date, tl->type) >= len-1) {
> -			update_tm(tm, now, tl->length * *num);
> +			time_t length = tl->length, num_t = *num;
> +			time_t seconds;
> +#ifndef is_unsigned_type
> +			seconds = length * num_t;
> +#else
> +			time_t max_val = is_unsigned_type(length)
> +				? maximum_unsigned_value_of_type(length)
> +				: maximum_signed_value_of_type(length);
> +			seconds = mult_overflows(length, num_t)
> +				? max_val : length * num_t;
> +#endif
> +			update_tm(tm, now, seconds);
>  			*num = 0;
>  			*touched = 1;
>  			return end;
> @@ -1368,8 +1379,15 @@ static const char *approxidate_digit(const char *date, struct tm *tm, int *num,
>  	}
>  
>  	/* Accept zero-padding only for small numbers ("Dec 02", never "Dec 0002") */
> -	if (date[0] != '0' || end - date <= 2)
> +	if (date[0] != '0' || end - date <= 2) {
> +#ifdef is_unsigned_type
> +		if (is_unsigned_type((time_t)0) &&
> +		    (number > INT_MAX ||
> +		     number > maximum_unsigned_value_of_type((time_t)0)))
> +			return NULL;
> +#endif
>  		*num = number;
> +	}
>  	return end;
>  }
>  
> @@ -1398,6 +1416,10 @@ static timestamp_t approxidate_str(const char *date,
>  		if (isdigit(c)) {
>  			pending_number(&tm, &number);
>  			date = approxidate_digit(date-1, &tm, &number, time_sec);
> +			if (!date) {
> +				*error_ret = 1;
> +				return 0;
> +			}
>  			touched = 1;
>  			continue;
>  		}

      reply	other threads:[~2026-10-14 21:44 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-14  6:09 [PATCH 0/5] Address overflows pointed out by Coverity Johannes Schindelin via GitGitGadget
2026-10-14  6:09 ` [PATCH 1/5] archive-tar: guard get_path_prefix against zero-length input Johannes Schindelin via GitGitGadget
2026-10-14  6:09 ` [PATCH 2/5] http: use `size_t` for byte position in fwrite_sha1_file Johannes Schindelin via GitGitGadget
2026-10-14  6:09 ` [PATCH 3/5] wrapper: reject insanely large byte counts when reading/writing Johannes Schindelin via GitGitGadget
2026-10-14 11:37   ` Phillip Wood
2026-10-14  6:09 ` [PATCH 4/5] git-compat-util: add `signed_mult_overflows` and `mult_overflows` macros Johannes Schindelin via GitGitGadget
2026-10-14  6:09 ` [PATCH 5/5] date: avoid overflow in approxidate relative-time multiplication Johannes Schindelin via GitGitGadget
2026-10-14 21:44   ` Junio C Hamano [this message]

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=xmqq4ieoq7n0.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=johannes.schindelin@gmx.de \
    /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.