Thanks for the explanation, but I had already understood. Maybe my
question was not quite clear? I will try to do better.
Put briefly: Are the results in testoutput18 as per PCRE2 SVN 362
correct? In particular, for this section (line 61-65):
/abc.def/
*** Failers
No match: POSIX code 17: match failed
abc\ndef
No match: POSIX code 17: match failed
I get a match instead of a failure.
If the failure is the expected result, I must look at my code. If a
match is expected, testouput18 should be corrected.
Ralf
On 03.09.2015 17:14, [email protected] wrote:
I'm afraid you have misunderstood. PCRE's POSIX API is just that: it
uses the POSIX function calls regcomp() and regex() as an interface to
the PCRE library. The "posix" modifier in pcre2test causes it to test
these functions. However, using these functions does not imply POSIX
pattern matching, though there are some options that change PCRE's
behaviour. The documentation says "It is not possible to get PCRE2 to
obey POSIX semantics, but then PCRE2 was never intended to be a POSIX
engine." and also "The default POSIX newline handling can be obtained by
setting PCRE2_DOTALL and PCRE2_DOLLAR_ENDONLY, but there is no way to
make PCRE2 behave exactly as for the REG_NEWLINE action."
Setting REG_NEWLINE in regcomp() sets PCRE2_MULTILINE when
pcre2_compile() is called. Setting REG_DOTALL sets PCRE2_DOTALL (which
makes '.' match newlines). From pcre2test, using /m sets PCRE2_MULTILINE
(which translates to REG_NEWLINE for the regcomp() call), and /s sets
PCRE2_DOTALL. Setting "posix" just uses the POSIX API; it does not
change matching semantics.
Perhaps the documentation could be made more clear. I will try to do so.
--
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
