[PATCH] Re: Several PCRE module oddities

[PATCH] Re: Several PCRE module oddities

[Bart Schaefer]

[Redirected from zsh-users]

On Jul 20, 12:24pm, Roman Neuhauser wrote:
} Subject: Re: Several PCRE module oddities
}
} maybe the slightly shorter version?
} 
} > -    if (offset_start < 0 || offset_start >= (subject_len ? subject_len : 1))

I was thinking more of using offset_start < 0 as a flag for whether the
-n option appears at all, since the return value of getposint() can be
independently examined.

Here's a new patch, making CASE_MATCH apply only to the =~ operator, and
removing dead code (the "not enough arguments" test is done by the generic
builtin command handler and lacked a failure return in bin_pcre_match).


diff --git a/Doc/Zsh/mod_pcre.yo b/Doc/Zsh/mod_pcre.yo
index 6ab5a19..faada28 100644
--- a/Doc/Zsh/mod_pcre.yo
+++ b/Doc/Zsh/mod_pcre.yo
@@ -80,6 +80,14 @@ Matches a string against a perl-compatible regular expression.
 
 For example,
 
-[[ "$text" -pcre-match ^d+$ ]] && print text variable contains only "d's".
+example([[ "$text" -pcre-match ^d+$ ]] &&
+print text variable contains only "d's".)
+
+pindex(REMATCH_PCRE)
+pindex(NO_CASE_MATCH)
+If the tt(REMATCH_PCRE) option is set, the tt(=~) operator is equivalent to
+tt(-pcre-match), and the tt(NO_CASE_MATCH) option may be used.  Note that
+tt(NO_CASE_MATCH) never applies to the tt(pcre_match) builtin, instead use
+the tt(-i) switch of tt(pcre_compile).
 )
 enditem()
diff --git a/Src/Modules/pcre.c b/Src/Modules/pcre.c
index cb9f8ef..0e43ab7 100644
--- a/Src/Modules/pcre.c
+++ b/Src/Modules/pcre.c
@@ -274,7 +274,7 @@ bin_pcre_match(char *nam, char **args, Options ops, UNUSED(int func))
     int return_value = 1;
     /* The subject length and offset start are both int values in pcre_exec */
     int subject_len;
-    int offset_start = 0;
+    int offset_start = -1;
     int want_offset_pair = 0;
 
     if (pcre_pattern == NULL) {
@@ -289,14 +289,11 @@ bin_pcre_match(char *nam, char **args, Options ops, UNUSED(int func))
 	matched_portion = OPT_ARG(ops,c);
     }
     if(OPT_HASARG(ops,c='n')) { /* The offset position to start the search, in bytes. */
-	offset_start = getposint(OPT_ARG(ops,c), nam);
+	if ((offset_start = getposint(OPT_ARG(ops,c), nam) < 0))
+	    return 1;
     }
     /* For the entire match, 'Return' the offset byte positions instead of the matched string */
     if(OPT_ISSET(ops,'b')) want_offset_pair = 1; 
-
-    if(!*args) {
-	zwarnnam(nam, "not enough arguments");
-    }
     
     if ((ret = pcre_fullinfo(pcre_pattern, pcre_hints, PCRE_INFO_CAPTURECOUNT, &capcount)))
     {
@@ -311,7 +308,7 @@ bin_pcre_match(char *nam, char **args, Options ops, UNUSED(int func))
     unmetafy(plaintext, NULL);
     subject_len = (int)strlen(plaintext);
 
-    if (offset_start < 0 || offset_start >= subject_len)
+    if (offset_start > 0 && offset_start >= subject_len)
 	ret = PCRE_ERROR_NOMATCH;
     else
 	ret = pcre_exec(pcre_pattern, pcre_hints, plaintext, subject_len, offset_start, 0, ovec, ovecsize);
@@ -345,6 +342,8 @@ cond_pcre_match(char **a, int id)
 
     if (zpcre_utf8_enabled())
 	pcre_opts |= PCRE_UTF8;
+    if (isset(REMATCHPCRE) && !isset(CASEMATCH))
+	pcre_opts |= PCRE_CASELESS;
 
     lhstr = cond_str(a,0,0);
     rhre = cond_str(a,1,0);

Re: [PATCH] Several PCRE module oddities

[Jun T.]

On 2014/07/21, at 01:55, Bart Schaefer wrote:
> I was thinking more of using offset_start < 0 as a flag for whether the
> -n option appears at all, since the return value of getposint() can be
> independently examined.
> 
> Here's a new patch, 
(snip)
> -    int offset_start = 0;
> +    int offset_start = -1;
(snip)
> -    if (offset_start < 0 || offset_start >= subject_len)
> +    if (offset_start > 0 && offset_start >= subject_len)

With this patch, if the -n option is not given, then offset_start remains
as -1 and pcre_exec() (line 314)

    ret = pcre_exec(pcre_pattern, pcre_hints, plaintext, subject_len, offset_start, 0, ovec, ovecsize);

fails with ret==-24, and V07pcre.ztst fails with errors like 

Error output:
(eval):pcre_match:2: error in pcre_exec [-24]

Maybe offset_start can be initialized to 0 as in the original code?

Re: [PATCH] Several PCRE module oddities

[Bart Schaefer]

On Jul 23, 10:18pm, Jun T. wrote:
} Subject: Re: [PATCH] Several PCRE module oddities
}
} 
} On 2014/07/21, at 01:55, Bart Schaefer wrote:
} > I was thinking more of using offset_start < 0 as a flag for whether the
} > -n option appears at all, since the return value of getposint() can be
} > independently examined.
} 
} With this patch, if the -n option is not given, then offset_start remains
} as -1 and pcre_exec() (line 314)

Well, drat.  I was sure I'd run "make check".  How did I miss that?

} Maybe offset_start can be initialized to 0 as in the original code?

Yes, thinko on my part.  I started with the idea that -n 0 was a case
that needed to be differentiated, but in the end that doesn't seem to
be the case.

Thanks for catching.


diff --git a/Src/Modules/pcre.c b/Src/Modules/pcre.c
index 0e43ab7..040a33f 100644
--- a/Src/Modules/pcre.c
+++ b/Src/Modules/pcre.c
@@ -274,7 +274,7 @@ bin_pcre_match(char *nam, char **args, Options ops, UNUSED(int func))
     int return_value = 1;
     /* The subject length and offset start are both int values in pcre_exec */
     int subject_len;
-    int offset_start = -1;
+    int offset_start = 0;
     int want_offset_pair = 0;
 
     if (pcre_pattern == NULL) {