https://bugs.exim.org/show_bug.cgi?id=2222
Bug ID: 2222
Summary: pcre2grep does not support searching for \0 via -f,
even though pcre2 itself supports this
Product: PCRE
Version: 10.30 (PCRE2)
Hardware: x86
OS: Linux
Status: NEW
Severity: bug
Priority: medium
Component: Code
Assignee: p...@hermes.cam.ac.uk
Reporter: ava...@gmail.com
CC: pcre-dev@exim.org
I've implemented support for git grep -f <pat> where <pat> is a regex
containing \0 (not yet in git upstream).
So I was surprised to see that pcre2grep itself doesn't support this, in fact
it has a bug where it just cuts the pattern off at \0:
$ perl -wE 'say "foo\0bar"' >file; perl -wE 'say "f.*\0[x].*a"' >p;
./pcre2grep -a -f p file; echo $?
foobar
0
GNU grep does the right thing:
$ perl -wE 'say "foo\0bar"' >file; perl -wE 'say "f.*\0[b].*a"' >p; grep -o
-
a -f p file; echo $?
fooba
0
$ perl -wE 'say "foo\0bar"' >file; perl -wE 'say "f.*\0[f].*a"' >p; grep -a
-f p file; echo $?
1
Looking at the source the reason is obvious, read_pattern_file() calls strlen()
on the line, and add_pattern() itself takes a char*.
I don't actually need this myself, just thought you'd like to know. Seems like
a nice thing to add since not many grep engines do this correctly, and it would
be relatively easy to add since pcre2_match() supports it, just not the part of
pcre2grep which passes strings around.
--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
