Re: [pcre-dev] issues with EBCDIC and pcretest

Startseite
Nachricht löschen
Autor: Ze'ev Atlas
Datum:  
To: pcre-dev@exim.org
Betreff: Re: [pcre-dev] issues with EBCDIC and pcretest
<SNIP>That is not right, and I suspect all the others are the same. The \p and
\P escapes test Unicode properties (see the note at the top of test 11).
They should not work in an environment where Unicode properties are not
supported. You should get a compile-time error (unless you have
accidentally set SUPPORT_UCP in config.h). It seems to have treated \p
as a literal "p", which is correct if SUPPORT_UCP is not set and the
PCRE_EXTRA option is set (which it doesn't seem to be, so that's a bit
odd).

Basically, I would not expect \p and \P to be useful in EBCDIC
environments. What happens if you use them outside a class? E.G.

/\p{L}/B

<SNIP>
Once the test is out of the class, it fails as it should
/\p{L}/BM                                                                  Failed: support for \P, \p, and \X has not been compiled at offset 1                                                                                  /\p{L}/B                                                                   Failed: support for \P, \p, and \X has not been compiled at offset 1   
So the issue is confined to \p and \P as the first element in a class.  I do not use .SUPPORT_UCP, nor  PCRE_EXTRA.
Note that \p in a class it fails as it should, if I add the 8:
/[\p{L}]/8BM                                                             Failed: this version of PCRE is compiled without UTF support at offset 0  
Obviously, I know that \p and \P are useless, but the tests are odd, and I am trying to reduce the level of oddity as much as I could.                                                                           
Ze'ev Atlas