[PATCH] regex: fix newline matching with negated brackets

[PATCH] regex: fix newline matching with negated brackets

[Julien Ramseier]

[-- Attachment #1: Type: text/plain, Size: 408 bytes --]

With REG_NEWLINE, POSIX says:
"A <newline> in string shall not be matched by a period outside
 a bracket expression or by any form of a non-matching list"

musl currently matches newlines with negated brackets, even if
REG_NEWLINE is used. Attached patch fixes the issue, although
I'm not sure if it's the best way to do it.

Also see similar glibc bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=3957


[-- Attachment #2: regcomp-newline-neg-bracket.patch --]
[-- Type: application/octet-stream, Size: 774 bytes --]

diff --git a/src/regex/regcomp.c b/src/regex/regcomp.c
index 5a7b53a..fb24556 100644
--- a/src/regex/regcomp.c
+++ b/src/regex/regcomp.c
@@ -636,6 +636,20 @@ static reg_errcode_t parse_bracket(tre_parse_ctx_t *ctx, const char *s)
 		goto parse_bracket_done;
 
 	if (neg.negate) {
+		/*
+		 * With REG_NEWLINE, POSIX requires that newlines are not matched by
+		 * any form of a non-matching list.
+		 */
+		if (ctx->cflags & REG_NEWLINE) {
+			lit = tre_new_lit(&ls);
+			if (!lit) {
+				err = REG_ESPACE;
+				goto parse_bracket_done;
+			}
+			lit->code_min = '\n';
+			lit->code_max = '\n';
+			lit->position = -1;
+		}
 		/* Sort the array if we need to negate it. */
 		qsort(ls.a, ls.len, sizeof *ls.a, tre_compare_lit);
 		/* extra lit for the last negated range */

Re: [PATCH] regex: fix newline matching with negated brackets

[Julien Ramseier]

Again with inline patch.
I suspect my emails are not received by anyone when adding an attachment...

diff --git a/src/regex/regcomp.c b/src/regex/regcomp.c
index 5a7b53a..fb24556 100644
--- a/src/regex/regcomp.c
+++ b/src/regex/regcomp.c
@@ -636,6 +636,20 @@ static reg_errcode_t parse_bracket(tre_parse_ctx_t *ctx, const char *s)
 		goto parse_bracket_done;
 
 	if (neg.negate) {
+		/*
+		 * With REG_NEWLINE, POSIX requires that newlines are not matched by
+		 * any form of a non-matching list.
+		 */
+		if (ctx->cflags & REG_NEWLINE) {
+			lit = tre_new_lit(&ls);
+			if (!lit) {
+				err = REG_ESPACE;
+				goto parse_bracket_done;
+			}
+			lit->code_min = '\n';
+			lit->code_max = '\n';
+			lit->position = -1;
+		}
 		/* Sort the array if we need to negate it. */
 		qsort(ls.a, ls.len, sizeof *ls.a, tre_compare_lit);
 		/* extra lit for the last negated range */


> Le 17 mars 2017 à 14:33, Julien Ramseier <j.ramseier@gmail.com> a écrit :
> 
> With REG_NEWLINE, POSIX says:
> "A <newline> in string shall not be matched by a period outside
> a bracket expression or by any form of a non-matching list"
> 
> musl currently matches newlines with negated brackets, even if
> REG_NEWLINE is used. Attached patch fixes the issue, although
> I'm not sure if it's the best way to do it.
> 
> Also see similar glibc bug:
> https://sourceware.org/bugzilla/show_bug.cgi?id=3957
> 
> <regcomp-newline-neg-bracket.patch>

Re: Re: [PATCH] regex: fix newline matching with negated brackets

[Rich Felker]

On Sat, Mar 18, 2017 at 04:00:11PM +0100, Julien Ramseier wrote:
> Again with inline patch.
> I suspect my emails are not received by anyone when adding an attachment...

No, attached patch is fine and preferable. I saw the patch but I'm
waiting for nsz (who understands the regex code much better) to check
and make sure it looks ok.

Rich

Re: Re: [PATCH] regex: fix newline matching with negated brackets

[Szabolcs Nagy]

* Julien Ramseier <j.ramseier@gmail.com> [2017-03-18 16:00:11 +0100]:
> diff --git a/src/regex/regcomp.c b/src/regex/regcomp.c
> index 5a7b53a..fb24556 100644
> --- a/src/regex/regcomp.c
> +++ b/src/regex/regcomp.c
> @@ -636,6 +636,20 @@ static reg_errcode_t parse_bracket(tre_parse_ctx_t *ctx, const char *s)
>  		goto parse_bracket_done;
>  
>  	if (neg.negate) {
> +		/*
> +		 * With REG_NEWLINE, POSIX requires that newlines are not matched by
> +		 * any form of a non-matching list.
> +		 */
> +		if (ctx->cflags & REG_NEWLINE) {
> +			lit = tre_new_lit(&ls);
> +			if (!lit) {
> +				err = REG_ESPACE;
> +				goto parse_bracket_done;
> +			}
> +			lit->code_min = '\n';
> +			lit->code_max = '\n';
> +			lit->position = -1;
> +		}
>  		/* Sort the array if we need to negate it. */
>  		qsort(ls.a, ls.len, sizeof *ls.a, tre_compare_lit);
>  		/* extra lit for the last negated range */
> 

looks good.
thanks

> 
> > Le 17 mars 2017 à 14:33, Julien Ramseier <j.ramseier@gmail.com> a écrit :
> > 
> > With REG_NEWLINE, POSIX says:
> > "A <newline> in string shall not be matched by a period outside
> > a bracket expression or by any form of a non-matching list"
> > 
> > musl currently matches newlines with negated brackets, even if
> > REG_NEWLINE is used. Attached patch fixes the issue, although
> > I'm not sure if it's the best way to do it.
> > 
> > Also see similar glibc bug:
> > https://sourceware.org/bugzilla/show_bug.cgi?id=3957
> > 
> > <regcomp-newline-neg-bracket.patch>

Re: Re: [PATCH] regex: fix newline matching with negated brackets

[Rich Felker]

On Sun, Mar 19, 2017 at 04:30:43AM +0100, Szabolcs Nagy wrote:
> * Julien Ramseier <j.ramseier@gmail.com> [2017-03-18 16:00:11 +0100]:
> > diff --git a/src/regex/regcomp.c b/src/regex/regcomp.c
> > index 5a7b53a..fb24556 100644
> > --- a/src/regex/regcomp.c
> > +++ b/src/regex/regcomp.c
> > @@ -636,6 +636,20 @@ static reg_errcode_t parse_bracket(tre_parse_ctx_t *ctx, const char *s)
> >  		goto parse_bracket_done;
> >  
> >  	if (neg.negate) {
> > +		/*
> > +		 * With REG_NEWLINE, POSIX requires that newlines are not matched by
> > +		 * any form of a non-matching list.
> > +		 */
> > +		if (ctx->cflags & REG_NEWLINE) {
> > +			lit = tre_new_lit(&ls);
> > +			if (!lit) {
> > +				err = REG_ESPACE;
> > +				goto parse_bracket_done;
> > +			}
> > +			lit->code_min = '\n';
> > +			lit->code_max = '\n';
> > +			lit->position = -1;
> > +		}
> >  		/* Sort the array if we need to negate it. */
> >  		qsort(ls.a, ls.len, sizeof *ls.a, tre_compare_lit);
> >  		/* extra lit for the last negated range */
> > 
> 
> looks good.
> thanks

Thanks for reviewing. Committing it.

Rich