Re: [PATCH 2/4] avoid computing zero offsets from NULL pointer
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jan 27, 2020, 20:03 UTC
- Message-ID
- <xmqq7e1cbr9w.fsf@gitster-ct.c.googlers.com>
- In-Reply-To
- <20200125053834.GB744673@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 20 quoted lines
> switch to iterating with a numeric index (as we do in sequencer.c here).
> In other cases (like the cache_end one) the use of an end pointer is
> more natural; we can keep that by just explicitly checking for NULL when
> assigning the end pointer.
>
> diff --git a/xdiff-interface.c b/xdiff-interface.c
> index 8509f9ea22..2f1fe48512 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->size;
> - char *bp = b->ptr + b->size;
> + char *ap = a->ptr ? a->ptr + a->size : a->ptr;
> + char *bp = b->ptr ? 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)) {Isn't it a bug for a->ptr or b->ptr to be NULL here? Even if we manage to assign ap = a->ptr = NULL without complaints, how would that memcmp work?
Is it that the corresponding .size would always be 0 if .ptr is NULL that protects us?
A bit puzzled.