All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 2/4] avoid computing zero offsets from NULL pointer
Date: Tue, 28 Jan 2020 21:16:39 -0800	[thread overview]
Message-ID: <xmqqblqm7sg8.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <20200129023146.GA596379@coredump.intra.peff.net> (Jeff King's message of "Tue, 28 Jan 2020 21:31:46 -0500")

Jeff King <peff@peff.net> writes:

> Yep, but it's not much different than the hundreds of other function
> interfaces we have where sometimes you can pass NULL and sometimes not.
>
> So anyway. What do we want to do here? The fix I have? Something more
> elaborate and reusable? Or perhaps just switch it to:

My preference was to take the patch as-is, as it was clear enough,
before seeing this one ...

> diff --git a/xdiff-interface.c b/xdiff-interface.c
> index 3cd2ac2855..4d20069302 100644
> --- a/xdiff-interface.c
> +++ b/xdiff-interface.c
> @@ -84,8 +84,8 @@ static void trim_common_tail(mmfile_t *a, mmfile_t *b)
>  {
>  	const int blk = 1024;
>  	long trimmed = 0, recovered = 0;
> -	char *ap = a->ptr ? a->ptr + a->size : a->ptr;
> -	char *bp = b->ptr ? b->ptr + b->size : b->ptr;
> +	char *ap = a->size ? a->ptr + a->size : a->ptr;
> +	char *bp = b->size ? b->ptr + b->size : b->ptr;
>  	long smaller = (a->size < b->size) ? a->size : b->size;
>  
>  	while (blk + trimmed <= smaller && !memcmp(ap - blk, bp - blk, blk)) {
>
> By checking "size" instead of "ptr", then we know that the addition is a
> noop. And we'd continue to catch a NULL pointer mixed with a non-zero
> length (as a segfault). And a non-NULL pointer with a zero length does
> the right thing.

which makes quite a lot of sense.

  reply	other threads:[~2020-01-29  5:16 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-25  5:35 [PATCH 0/4] more clang/sanitizer fixes Jeff King
2020-01-25  5:37 ` [PATCH 1/4] merge-recursive: silence -Wxor-used-as-pow warning Jeff King
2020-01-25 17:27   ` Junio C Hamano
2020-01-25 19:55     ` Jeff King
2020-01-25 20:50       ` Elijah Newren
2020-01-25 23:57         ` Jeff King
2020-01-27 19:17       ` Junio C Hamano
2020-01-25  5:38 ` [PATCH 2/4] avoid computing zero offsets from NULL pointer Jeff King
2020-01-27 20:03   ` Junio C Hamano
2020-01-27 21:19     ` Jeff King
2020-01-28 18:03       ` Junio C Hamano
2020-01-29  2:31         ` Jeff King
2020-01-29  5:16           ` Junio C Hamano [this message]
2020-01-29  5:46             ` Jeff King
2020-01-25  5:39 ` [PATCH 3/4] xdiff: avoid computing non-zero offset " Jeff King
2020-01-25  5:41 ` [PATCH 4/4] obstack: avoid computing offsets " Jeff King
2020-01-25  5:44   ` [PATCH v2 " 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=xmqqblqm7sg8.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --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.