Re: [PATCH] PCRE/NUL: pass NUL in for text, handle NUL out

[Phil Pennock <zsh-workers+phil.pennock@xxxxxxxxxxxx>]

On 2017-06-21 at 09:59 +0100, Peter Stephenson wrote:
> On Thu, 15 Jun 2017 16:40:50 -0400
> Phil Pennock <zsh-workers+phil.pennock@xxxxxxxxxxxx> wrote:
> > +# Embedded NULs allowed in plaintext, but not in RE (although \0 as two-chars allowed)
> > +  [[ $'a\0bc\0d' =~ '^(a\0.)(.+)$' ]]
> > +  print "${#MATCH}; ${#match[1]}; ${#match[2]}"
> > +>6; 3; 3
> 
> Not sure what's going on here but there needs to be a status /
> description line.

How strange, that test passed when I tried it out locally but I would
have expected a failure.  You're right, sorry about that.

Status/description line:

0:ensure ASCII NUL passes in and out of matched plaintext

I didn't see a point in trying to figure out text-matches of exact
NUL-containing strings in the test-suite, when we could just match the
length of the strings.  There is logic for passing the full string in
now, and for fixing the length of $MATCH, and separately for the lengths
of the items in $match; testing both that $match works twice (ie, ovec
iteration is not busted) and that `.+` swallows the NUL, not just
explicit \0 matching.  It seemed a concise way to test all the changes
and detect regression.

> Was there are a response to Stephane's further suggestion?

The <<replace NUL with "\0">> suggestion was withdrawn within the same
paragraph, I agree that the behaviour I implemented is the best choice.
;)  As for changing \Q...\E support, that's an entirely different issue,
it's a feature request where this patch is a bug-fix.

My response is "sounds great, feature patches welcome; any issues with
this bug-fix?"

-Phil