summaryrefslogtreecommitdiff
path: root/apple_remote
diff options
context:
space:
mode:
authorStephan Bergmann <sbergman@redhat.com>2014-12-17 15:34:14 +0100
committerStephan Bergmann <sbergman@redhat.com>2014-12-17 16:39:32 +0100
commit0ba6360363fb73b5b200bbc486ed8eeac5f3d337 (patch)
tree18146e0c4495301affa72baaae66ed2913484967 /apple_remote
parent7d70efaac360dbbd9bea2d51b1ae53b577fc6559 (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 'apple_remote')
0 files changed, 0 insertions, 0 deletions