git.vger.kernel.org archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).