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, ph10@??? 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.
