...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 379fe0409e7973b36210cffa3dd1dfd4032f0ecc "Assume that
this code wants to append a number, not a character" and
dc148335a6a438848325f24c49198fba81043279 "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/20036
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
...found regression e31205f3ec1f941ab5a188bfde6329edf2acc55b
"EditUndoRemoveChars::GetStr must return a reference" and dubious code
0e23f7b0839df68d277186b4df54ba391ac3406a "Lets assume this doesn't want to
update m_pForcedPrefix->GetText() anyway" in addition to the apparent sillies
directly fixed in this commit.
Introduces HAVE_CXX11_REF_QUALIFIER.
Change-Id: I564e98254fd53c1dd9b34193d7057c59721ee24c
Add move constructor and appropriately overloaded assignment operator to
rtl::Reference, and add basic unit tests for the reference counting of
rtl::Reference.
Change-Id: Ia7ff5d786bdf3b17709cec06608c91e22379746c
Reviewed-on: https://gerrit.libreoffice.org/19762
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
find places where we do not need to be passing a parameter to a
function, because that function has a default value which matches the
value we are passing.
Change-Id: I04d1fd6275204dd4925e6563282464f461123632
(This is no issue for OUString, as it has two ctors taking a single pointer
argument, so passing a null pointer is ambiguous anyway.)
Change-Id: I36f44b29eb84eb83e284fa080d706eabb4b485d5
...from most rtl/bootstrap.h functions. They are effectively only called from
C++ code (there is no plain C UNO binding), so it should be fine to let std
exceptions (like bad_alloc or length_error) propagate from their implementations
to call sites.
(The exception is rtl_bootstrap_args_close, which is typically called from C++
dtors, so should not throw anyway.)
This would strictly speaking be an [API CHANGE], but it should make no practical
difference whether a process terminates abruptly because an exception cannot
pass through a SAL_THROW_EXTERN_C() nothrow specification or because legacy
client code does not expect exceptions to be thrown from functions from which
SAL_THROW_EXTERN_C() has now been removed.
Change-Id: I08e8479e9c5731e46021aadd6a725c1793024d10
This reverts commit 5cba714b4d03ed54debf71534ad8c8edc383a01e, now including a
workaround for <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53658> "internal
compiler error -- segmentation fault."
Change-Id: I31f6d9ddcb0b884134703df2b9dc1800ba0a84be
This reverts commit 4d4f3512db0cf0bf47c2ba1b39c3813842903ef7, at least "gcc
version 4.8.3 20140627 [gcc-4_8-branch revision 212064] (SUSE Linux)" fails with
"include/rtl/stringutils.hxx:175:49: internal compiler error: Segmentation
fault."
...by making all places that accept a string literal via ConstCharArrayDetector
also accept an OUStringLiteral1 via ConstCharArrayDetector (which required some
tweaking of the ConstCharArrayDetector internals). That removes the need for
special-purpose OUStringLiteral1 overloads, and will allow OUStringLiteral1 to
be used in more places.
Change-Id: I370de8480e02f8423cde5677dd38479b81bccdb2
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>, modifying the patch to
carefully keep the undefined behavior in the already existing additions that may
potentially overflow, instead of making the static_cast<sal_Int32> introduction
look like end - pData->buffer will be guaranteed to fit into sal_Int32 (which it
is not).
Change-Id: Id2fb64dc4585dae34257be6968a8905254a3b42d
...with numeric values that are not meant to be characters. Inspired by
<https://gerrit.libreoffice.org/#/c/16339/> "OUString: add constructor from
single Unicode code point" and ecaf1cb3861c1b519a1495487fc796884cf37b92 "seems
to be what was meant." Found e46e8d19458fd64ff20b1013e5eeabd07e62379c "Shall
this produce a string representation of a number?" and
f2a0e4032734d6be635f14ade3dea499c29ec6c2 "Don't truncate a UTF-32 code point to
a UTF-16 code unit."
(LIBO_INTERNAL_ONLY mostly because it uses a C++11 delegating ctor for
simplicity, but also because it requires mild modifications to client code, see
additional changes in this commit and some other recent commits.)
Change-Id: I8a156f01d1b772c6052d7afaa088ae13ed234e2b
Document that in README.lifecycle; the problem is that our constructors
currently take and release references left/right on the object being
created, which ... means we need an initial reference.
Change-Id: I5de952b73ac67888c3fbb150d4a7cde2a7bc9abf
Create 4 new formats enums rtl_math_StringFormat:
rtl_math_StringFormat_E1, rtl_math_StringFormat_E2,
rtl_math_StringFormat_G1, rtl_math_StringFormat_G2
to 1 or 2 digits in exponent for scientific notation.
Set General format to use rtl_math_StringFormat_E2.
Set trendline equation in status bar to use rtl_math_StringFormat_E1
Change-Id: I41466a6d4ba808ba5b9b38ba252b37c6b4560f12
Reviewed-on: https://gerrit.libreoffice.org/14562
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
Also remove some now redundant asserts from headers.
Some of these actually trigger on unit tests so are commented out.
Change-Id: I07c6b2b2bd175361691a141f22eec584e3ab8f0b
...by adding some further SAL_DLLPUBLIC_RTTI type annotations (cf.
b4f6b26b5a1a78fecfa95ec2eb7ac8b80495d8aa "SAL_DLLPUBLIC_RTTI for proper RTTI
visibility for LLVM") and by making sure relevant function types do not use
incomplete types in their parameter and return types (which would make the RTTI
hidden).
Change-Id: Id7aadcbc0704b9759968ae36266fc9ce11a2e340
