PATCH: parse_class would underallocate if posix character classes are used

---

>> I was able to reproduce this,
>
> Does the patch resolve it, then?

It does, but it seems to try and track nested character classes which
wouldn't be valid anyway, and the loop later on would behave
differently. I think it'd be safe since it'd always abort earlier than
the nesting checking code Han submitted.

This patch uses the same kind of logic as the later loop that just allows
one level of [:foo:] inside the [] class.

Han's patch also produces an error if the posix character class itself
is unknown, this doesn't, but that is an entirely separate change.

 Src/Zle/complete.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/Src/Zle/complete.c b/Src/Zle/complete.c
index 5152764b8c..4bc048776a 100644
--- a/Src/Zle/complete.c
+++ b/Src/Zle/complete.c
@@ -496,9 +496,16 @@ parse_class(Cpattern p, char *iptr)
     }
 
     /* find end of class.  End character can appear literally first. */
-    for (optr = iptr; optr == iptr || *optr != endchar; optr++)
+    for (optr = iptr; optr == iptr || *optr != endchar; optr++) {
 	if (!*optr)
 	    return optr;
+	/* skip past POSIX class names like [:alpha:] */
+	if (endchar == ']' && *optr == '[' && optr[1] == ':') {
+	    char *nptr = strchr(optr+2, ':');
+	    if (nptr && nptr[1] == ']')
+		optr = nptr + 1;
+	}
+    }
     /*
      * We can always fit the parsed class within the same length
      * because of the tokenization (including a null byte).
-- 
2.38.1