|author||Stephan Bergmann <email@example.com>||2014-12-17 15:34:14 +0100|
|committer||Stephan Bergmann <firstname.lastname@example.org>||2014-12-17 16:39:32 +0100|
Garbage in, garbage out?
Non-ASCII characters (like Unicode "é", represented as two bytes \xC3 \xA9 in the UTF-8--encoded source file, and presumably passed trhough unchanged by compilers into the resulting string literal object) in the OUString "literal" ctor trigger a SAL_WARN_IF in rtl_uString_newFromLiteral, but are copied "verbatim" into the resulting OUString, which will thus contain UTF-16 code units \x00C3 \x00A9 (if char is unsigned) resp. \xFFC3 \xFFA9 (if char is signed). That assertXPathContent shall indeed match such an odd OUString value looks suspiciously like a bug elsewhere, papered over by a broken test. To be investigated. Change-Id: I07c995ad0e17235c214d7630fb34e8ef35d5ad30
Diffstat (limited to 'test')
0 files changed, 0 insertions, 0 deletions