Details
-
Bug
-
Resolution: Fixed
-
Minor
-
17.10.0
-
None
-
Unit
-
Unknown
-
N/A
-
N/A
-
Description
Problem
WikiPageUtil exposes its XML name validation through two char based methods:
public static boolean isValidXmlNameChar(char ch, boolean colonEnabled) public static boolean isValidXmlNameStartChar(char ch, boolean colonEnabled)
A char is a UTF-16 code unit, so it can only carry values in the range 0x0000-0xFFFF. The XML NameStartChar production however also allows the supplementary range #x10000-#xEFFFF, and isValidXmlNameStartChar does try to accept it with a final (ch >= 0x10000 && ch <= 0xEFFFF) alternative. That alternative can never hold for a char argument, which SonarQube reports as two java:S2198 issues ("will always return false" and "will always return true").
The consequence is not only dead code. A supplementary character reaches these methods as a surrogate pair, and each surrogate taken on its own (0xD800-0xDFFF) is rejected by every alternative. So isValidXmlName reports a perfectly valid XML name such as U+20000 followed by "foo" as invalid.
Proposal
Add int code point based overloads, which can express the whole production:
public static boolean isValidXmlNameChar(int codePoint, boolean colonEnabled) public static boolean isValidXmlNameStartChar(int codePoint, boolean colonEnabled)
and make isValidXmlName(String, boolean) walk the string by code point instead of by char, so that a supplementary character is validated as the single character it is.
Deprecate the char overloads and move them to a new xwiki-rendering-legacy-wikimodel backward compatibility module, so that the main artifact only exposes the code point based API while extensions compiled against the char signatures keep working.