Fix creation of some OUString from non-ASCII ordinary string literals

On platforms where char is signed,

> OUString aTmpName10(aTempDirectoryURL + "/\xE6\x9C\xAA\xE5\x91\xBD\xE5\x90\x8Dzhgb18030");

would have created, via addDataLiteral (include/rtl/stringconcat.hxx), an
OUString containing sign-extended char16_t counterparts of the \x char values
(\xE6 -> \uFFE6, etc.).

That caused CppunitTest_sal_osl
CPPUNIT_TEST_NAME=osl_FileBase::SystemPath_FileURL::getSystemPathFromFileURL_005
under an RTL_TEXTENCODING_ISO_8859_1 locale (e.g., LANG=C, as used by Fedora
when executing the %check part of libreoffice.spec) to fail on such signed-char
platforms (e.g., Linux x86_64) with

> [_RUN_____] osl_FileBase::SystemPath_FileURL::getSystemPathFromFileURL_005
> createTestDirectory failed: 21!
> sal/qa/osl/file/osl_File.cxx:267:osl_FileBase::SystemPath_FileURL::getSystemPathFromFileURL_005
> assertion failed
> - Expression: (osl::FileBase::E_None == nError) || (nError == osl::FileBase::E_NOENT)
> - In deleteTestDirectory function: remove Directory file:///tmp/?????????zhgb18030 -> result: 21

because FileURLToPath -> osl::detail::convertUrlToPathname ->
getSystemPathFromFileUrl<rtl::OString> -> decodeFromUtf8 -> convert (all
sal/osl/unx/file_url.cxx) would fail to convert those values beyond \u00FF to
RTL_TEXTENCODING_ISO_8859_1, ultimately returning osl_File_E_INVAL (i.e., 21).

(We could "fix" addDataLiteral in include/rtl/stringconcat.hxx, explicitly
converting from char to char16_t via unsigned char, but arguably that
concatenation construct should only be used with ASCII-only ordinary string
literals, similar to the restrictions for OUString construction from such
string literals.)

(Before 5a77636c9a638c86fd3de3afb6e88cf48f987b6a "WIN enable osl_File.cxx part
of CppUnitTest_sal_osl", that aTmpName10 was constructed as

> OUString aTmpName10(RTL_CONSTASCII_USTRINGPARAM( FILE_PREFIX TEST_PLATFORM TEST_PLATFORM_TEMP "/\xE6\x9C\xAA\xE5\x91\xBD\xE5\x90\x8Dzhgb18030" ));

but that would have caused similar issues, as RTL_CONSTASCII_USTRINGPARAM uses
RTL_TEXTENCODING_ASCII_US which converts non-ASCII chars to
RTL_TEXTENCODING_MS_1252 (see comment at aImplUSASCIIByteCvtData,
sal/textenc/textenc.cxx), which would have converted e.g. \x9C to \u2018, which
then would have failed to be converted to RTL_TEXTENCODING_ISO_8859_1.  And that
use of RTL_CONSTASCII_USTRINGPARAM had violated the requirements as stated in
include/rtl/ustring.h anyway:  "Each element of the referenced array must
represent an ASCII value in the range 0x00--0x7F.")

Whatever this crappy getSystemPathFromFileURL_005 actually wants to prove, it
happens to work now also for RTL_TEXTENCODING_ISO_8859_1 locales.

Change-Id: I044c4bd3aee4f7ea4f29737b6876cc55e4e6e436
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110714
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

0 files changed, 0 insertions, 0 deletions