Doc #62756 [Com]: preg documentation should mention '=' should not be first in character class

Edit report at https://bugs.php.net/bug.php?id=62756&edit=1 ID: 62756 Comment by: daverandom@php.net Reported by: marco at greenlightsolutions dot nl Summary: preg documentation should mention '=' should not be first in character class Status: Closed Type: Documentation Problem Package: Documentation problem PHP Version: Irrelevant Assigned To: daverandom Block user comment: N Private report: N New Comment: I've reworded the disallowed element list to match the error message as suggested. Note however that the "followed by a different character class that ends with that same literal" is not actually correct, also note that I cannot reproduce the error with the second example %[=~]|<[>=]% (http://3v4l.org/sdJ5M) - it's possible this was a bug in an earlier version of PCRE. The true rules relate to the fact that \ is not an escape character in POSIX bracket expressions, and in reality there *should* be no conflicts (the only way to cause a conflict would be with an empty character class []), and this is somewhat beyond the scope of the PCRE documentation. More information on the POSIX sequences that are the root cause of this problem can be found at http://www.regular-expressions.info/posixbrackets.html. Previous Comments: ------------------------------------------------------------------------ [2013-10-24 09:35:08] daverandom@php.net Automatic comment from SVN on behalf of daverandom Revision: http://svn.php.net/viewvc/?view=revision&amp;revision=331945 Log: Refactored disallowed POSIX bracket elements to match PCRE error message, per request on bug #62756 ------------------------------------------------------------------------ [2013-10-23 12:53:11] marco at greenlightsolutions dot nl The amended documentation is slightly inaccurate. The documentation states "Supplying an expression with a character class that both starts and ends with <literal>:</literal>, <literal>.</literal> or <literal>:</literal> characters to PCRE is interpreted as an attempt to use one of these unsupported features and causes a compilation error." Unfortunately, the compilation error is also triggered when "supplying an expression with a character class that start with a <literal>:</literal>, <literal>.</literal> or <literal>:</literal> character, followed by a different character class that ends with that same literal". Also, I strongly urge you to formulate the text in such a way that it includes the phrase "POSIX collating elements", so that the page will be a top search result when searching for the error message "Compilation failed: POSIX collating elements are not supported". ------------------------------------------------------------------------ [2013-10-23 08:41:57] daverandom@php.net This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. Documented at http://php.net/reference.pcre.pattern.posix ------------------------------------------------------------------------ [2013-10-23 08:40:48] daverandom@php.net Automatic comment from SVN on behalf of daverandom Revision: http://svn.php.net/viewvc/?view=revision&amp;revision=331924 Log: Document difference between PCRE and POSIX character classes. Fixes bug #62756. ------------------------------------------------------------------------ [2012-08-06 12:58:51] marco at greenlightsolutions dot nl You are right. It actually was part of a compound expression, and I'd overlooked that the other parts were also relevant. The following line generates the error message: $x=preg_match("%[=~]|<[>=]%", "test"); (PHP 5.3.8, PCRE 8.13.2011-08-16). Regardless, the documentation does not mention the '[=..=]' POSIX collating-element construct. It does not mention the '=' symbol at all. This should be fixed in the documentation. Ideally, the documentation should also contain the phrase 'POSIX collating element', so that it appears as a search result when people search for the text of the error message. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=62756 -- Edit this bug report at https://bugs.php.net/bug.php?id=62756&edit=1