-
Stephan Bergmann yazdı
...in LIBO_INTERNAL_ONLY, __cplusplus, non-MSVC case. It turns out that sal_Unicode happens to not be mangled into any symbols that make up the stable URE interface, so (for LIBO_INTERNAL_ONLY, at least) we are free to replace the typedef to sal_uInt16 with a typedef to any integral type layout-compatible with that. (sal_Unicode does appear in some symbols in sal's PRIVATE_textenc.1 section, but that is private between the sal and sal_textenc libraries, so changing those symbols does not require a change of SONAME.) C++11 chart16_t is the obvious choice (and will ultimately allow using u"..." to write literals of type array-of-sal_Unicode). Reportedly, char16_t is supported since GCC 4.4 and Clang 2.9 but will only be available in MSVC 2015. For plain C, we continue to use sal_uInt16. We could theoretically use C11 char16_t from <uchar.h>, but at least the Mac OS X 10.11 SDK still does not offer that C11 header. For MSVC, we continue to use wchar_t (which is actually unsigned short, due to /Zc:wchar_t-) for now. Potential options there include dropping /Zc:wchar_t- and using true wchar_t, or using C++11 char16_t once support for MSVC 2013 is dropped. Some code needed to be adapted that was written in a way assuming that sal_Unicode is unsigned short (which indicates that changing sal_Unicode for non-LIBO_INTERNAL_ONLY would be an ABI change). OUStringBuffer::append can now differentiate between being called with sal_Unicode (to append a single character) and erroneously being called with sal_uInt16 (intending to append a number's textual representation, for which the sal_Int32 overload must be used instead). Bugs found are 379fe040 "Assume that this code wants to append a number, not a character" and dc148335 "Assume this wants to append the numerical representation." The GDB support for pretty-printing of sal_Unicode-related data in solenv/gdb/libreoffice/sal.py can presumably be simplified now. Change-Id: I445b3a80e65b7cb004d9e08b38bdc9ee93bc9401 Reviewed-on: https://gerrit.libreoffice.org/20036Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com>
0b07406f