diff options
author | Stephan Bergmann <sbergman@redhat.com> | 2014-12-17 15:34:14 +0100 |
---|---|---|
committer | Stephan Bergmann <sbergman@redhat.com> | 2014-12-17 16:39:32 +0100 |
commit | 0ba6360363fb73b5b200bbc486ed8eeac5f3d337 (patch) | |
tree | 18146e0c4495301affa72baaae66ed2913484967 /i18npool | |
parent | 7d70efaac360dbbd9bea2d51b1ae53b577fc6559 (diff) |
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 'i18npool')
0 files changed, 0 insertions, 0 deletions