[PATCH v2 2/2] prefix_ref_iterator_advance(): relax the check of trim length

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Before the previous commit, `for_each_bad_bisect_ref()` called
`for_each_fullref_in_submodule()` in such a way as to trim the whole
refname away. This is a questionable use of the API, but is not ipso
facto dangerous, so tolerate it in case there are other callers
relying on this behavior. But continue to refuse to trim *more*
characters than the refname contains, as that really makes no sense.

Signed-off-by: Michael Haggerty <mhagger@xxxxxxxxxxxx>
---
 refs/iterator.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/refs/iterator.c b/refs/iterator.c
index 4cf449ef66..de52d5fe93 100644
--- a/refs/iterator.c
+++ b/refs/iterator.c
@@ -298,11 +298,11 @@ static int prefix_ref_iterator_advance(struct ref_iterator *ref_iterator)
 			 * you haven't already checked for via a
 			 * prefix check, whether via this
 			 * `prefix_ref_iterator` or upstream in
-			 * `iter0`). So if there wouldn't be at least
-			 * one character left in the refname after
-			 * trimming, report it as a bug:
+			 * `iter0`. So consider it a bug if we are
+			 * asked to trim off more characters than the
+			 * refname contains:
 			 */
-			if (strlen(iter->iter0->refname) <= iter->trim)
+			if (strlen(iter->iter0->refname) < iter->trim)
 				die("BUG: attempt to trim too many characters");
 			iter->base.refname = iter->iter0->refname + iter->trim;
 		} else {
-- 
2.11.0




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]