@matheusbsbs / matheus-bagliano / commits / b9c8e7f2fb

prefix_ref_iterator: don't trim too much

The `trim` parameter can be set independently of `prefix`. So if some caller were to set `trim` to be greater than `strlen(prefix)`, we could end up pointing the `refname` field of the iterator past the NUL of the actual reference name string. That can't happen currently, because `trim` is always set either to zero or to `strlen(prefix)`. But even the latter could lead to confusion, if a refname is exactly equal to the prefix, because then we would set the outgoing `refname` to the empty string. And we're about to decouple the `prefix` and `trim` arguments even more, so let's be cautious here. Report a bug if ever asked to trim a reference whose name is not longer than `trim`. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>

Michael Haggerty committed May 22, 2017 at 16:17 UTC b9c8e7f2fb6ee19defeaa2927a0af42b525d8b33

1 file changed +17 -1

refs/iterator.c

+17 -1

@@ -292,7 +292,23 @@ static int prefix_ref_iterator_advance(struct ref_iterator *ref_iterator)

292 if (!starts_with(iter->iter0->refname, iter->prefix))

293 continue;

294

295 - iter->base.refname = iter->iter0->refname + iter->trim;

295 + if (iter->trim) {

296 + /*

297 + * It is nonsense to trim off characters that

298 + * you haven't already checked for via a

299 + * prefix check, whether via this

300 + * `prefix_ref_iterator` or upstream in

301 + * `iter0`). So if there wouldn't be at least

302 + * one character left in the refname after

303 + * trimming, report it as a bug:

304 + */

305 + if (strlen(iter->iter0->refname) <= iter->trim)

306 + die("BUG: attempt to trim too many characters");

307 + iter->base.refname = iter->iter0->refname + iter->trim;

308 + } else {

309 + iter->base.refname = iter->iter0->refname;

310 + }

311 +

312 iter->base.oid = iter->iter0->oid;

313 iter->base.flags = iter->iter0->flags;

314 return ITER_OK;