From 07c5639b9af523f9672204cc048577154d5a3fc0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Carlo=20Marcelo=20Arenas=20Bel=C3=B3n?= Date: Sun, 29 Sep 2024 13:01:46 -0700 Subject: [PATCH] pcre2test: tighten \x{...} parsing in subject Eventhough it is documented that invalid escapes will be reported, the code would still allow a NUL to be generated when a non terminated \x{ escape was being used. Presume the fact that there was a test relying on it means that Perl might had done so at one time, but had confirmed that none does since at least 5.6.1, and indeed was silently failing with perltest.sh as well. Additionally, the code for overlong escapes was returning an incorrect value. Refactor the code to report the error in those cases, and hopefully adjust the test to match. While at it update related documentation in Perl's compatibility. --- doc/pcre2compat.3 | 12 ++++++--- doc/pcre2test.1 | 2 +- perltest.sh | 8 +++++- src/pcre2test.c | 54 +++++++++++++++++++++------------------- testdata/testinput10 | 3 ++- testdata/testinput12 | 2 +- testdata/testoutput10 | 3 ++- testdata/testoutput12-16 | 2 +- testdata/testoutput12-32 | 2 +- 9 files changed, 52 insertions(+), 36 deletions(-) diff --git a/doc/pcre2compat.3 b/doc/pcre2compat.3 index 74a9ce8a8..cc8b7709f 100644 --- a/doc/pcre2compat.3 +++ b/doc/pcre2compat.3 @@ -226,9 +226,15 @@ handled by PCRE2, either by the interpreter or the JIT. An example is /(?:|(?0)abcd)(?(R)|\ez)/, which matches a sequence of any number of repeated "abcd" substrings at the end of the subject. .P -23. From release 10.45, PCRE2 gives an error if \ex is not followed by a -hexadecimal digit or a curly bracket. It used to interpret this as the NUL -character. Perl still generates NUL, but warns in its warning mode. +23. Both PCRE2 and Perl error when \ex{ escapes are invalid, but Perl tries to +recover and prints a warning if the problem was that an invalid hexadecimal +digit was found, since PCRE2 doesn't have warnings it returns an error instead. +Additionally, Perl accepts \ex{} and generates NUL unlike PCRE2. +.P +24. From release 10.45, PCRE2 gives an error if \ex is not followed by a +hexadecimal digit or a curly bracket. It used to interpret this as the NUL +character. Perl still generates NUL, but warns when in warning mode in most +cases. . . .SH AUTHOR diff --git a/doc/pcre2test.1 b/doc/pcre2test.1 index 1313706bf..3ea58f72b 100644 --- a/doc/pcre2test.1 +++ b/doc/pcre2test.1 @@ -516,7 +516,7 @@ this makes it possible to construct invalid UTF-8 sequences for testing purposes. On the other hand, \ex{hh} is interpreted as a UTF-8 character in UTF-8 mode, generating more than one byte if the value is greater than 127. When testing the 8-bit library not in UTF-8 mode, \ex{hh} generates one byte -for values less than 256, and causes an error for greater values. +for values that could fit on it, and causes an error for greater values. .P In UTF-16 mode, all 4-digit \ex{hhhh} values are accepted. This makes it possible to construct invalid UTF-16 sequences for testing purposes. diff --git a/perltest.sh b/perltest.sh index b05500665..219fcbb4c 100755 --- a/perltest.sh +++ b/perltest.sh @@ -314,7 +314,13 @@ for (;;) } else { - $x = eval "\"$_\""; # To get escapes processed + s/(?