FS#2867, ACL processing may fail with utf-8 characters which include byte 'A0'.

[Chris--S]

More detailed discussion and explanations at https://bugs.dokuwiki.org/index.php?do=details&task_id=2867

Summary.

Under some circumstances '\s' may match bytes 'A0' & '85'. These bytes can occur as part of non-space utf8 characters. Conversely, '\S' may not match these bytes for the same reason.

[Chris--S]

More unit tests to come.

[splitbrain]

I wonder if we have this problem in other files as well confutils comes to mind. Should we grep the sources for \s and \S?

[splitbrain]

@Chris--S what's the status here? Can I merge this as is?

[Chris--S]

Problem fully understood. Test written. So yes, you can now.

Underlying problem, the characters which '/\s/' will match can vary depending on the locale. (see setlocale() & LC_CTYPE [1]).

Outside 3rd party libraries, there aren't so many uses of '\s'. In some of these uses the object string may not be able to contain non-ascii characters or the match must happen before they could occur (e.g. config files). Though, that is probably not the most robust of assumptions.

Three solutions:

• force locale to remove any problem LC_CTYPE, e.g. setlocale(LC_ALL,"C"); Unfortunately locale is a per process property, so it can be changed by another php script running its own setlocale() and conversely DokuWiki changing this value may upset other scripts.
• use 'u' flag. performance may have improved since php5.2.9, but it is still worse than not using 'u'. The character classes and metaclasses are all noted in PCRE docs as using a less efficient comparison mechanism when in UCP mode.[2]
• [ \t] or [ \t\r\n].

[1] - http://php.net/manual/en/function.setlocale.php
[2] - Matching characters by Unicode property is not fast, because PCRE has to do a multistage table lookup in order to find a character's property.