Some of the methods added in the commit below had the wrong name for the
character parameter in the documention.
commit ab871d3af9
Author: Neil Roberts <nroberts@libreoffice.org>
Date: Sun Apr 26 12:00:28 2026 +0200
[API CHANGE] rtl/string: Add startsWith/endsWith for a single character
Change-Id: I47eec8a7a6aca75f5735e3158125efc4cb44c734
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205716
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
A lot of places in the code are calling OUString::endsWith with a string
containing a single character. Similar to lastIndexOf, this patch
provides overloads to the two methods to have an optimised version for
the case when there is only one character.
It would be kind of nice if the compiler could handle this optimisation
itself, but it’s unlikely to work because the string version of endsWith
ends up calling rtl_ustr_shortenedCompare_WithLength which isn’t inline
and is defined outside of a header.
The main incentive to do this is to make it easier to change calls to
lastIndexOf that should really be endsWith, as in tdf#171853.
Change-Id: Iaba5a7db3211eb12b0a83f441c0a81e664da6eea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204363
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Tested-by: Jenkins
Move the approxDiff heuristic from the sc unnamed namespace to rtl::math and
disable floating-point contraction (FMA) for this function.
On ARM64 (Apple Silicon), the use of Fused Multiply-Add (FMA) results in
higher intermediate precision during floating-point operations. While
mathematically more accurate, this prevents legacy rounding heuristics in
approxDiff and approxValue from detecting and cleaning rounding artifacts
in series generation (e.g., 1.1 - 1.0).
Disabling fp-contract forces intermediate rounding to 64-bit IEEE 754
limits. This ensures the noise expected by the approximation logic is
present, restoring consistency with x86-64 behavior and fixing issues where
values like 6.0 are incorrectly rendered as 6.00000000000001.
Change-Id: I54a0f748be6cf817db1f3bdcfd2b355320c3a617
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/203233
Reviewed-by: Dan Williams <dcbw@libreoffice.org>
Tested-by: Jenkins
... and use in sw.
Should replace padToLength, where the number of added characters is
known in advance. Avoids creation of a string buffer for the task.
Change-Id: I90450e37926335d74421c6e38385e4c441e535d9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190341
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
It must only add characters up to terminating null, as its counterpart
ToStringHelper< char[ N ] > does, and as its own length implies.
Was this way ever since commit f1769094af
(round out StringConcat helpers with sal_Unicode* overloads, 2019-10-11).
Change-Id: I3e267789333dac23754e67b19ff596ad359868aa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/187791
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
This is a combined cherry-pick of the 10 commits
34f1a750a128e02aa3191e36a2c0b28371e96287 "sal: initial osl::File sand-boxing
commit for Unix.", 55243a397add76fcff8c67284ba57205a1512ca5 "lok: import allowed
paths from the SAL_ALLOWED_PATHS.", 148915ef6d4bfc38deb6d98fb14429d7e6e27129
"sal: osl::File allow to create files in sandbox",
479e2f5cb69ceef2ef6832630a342d7673d6782a "unconditionally include vector",
f04d38d5a88f422b80d2a37d1a1252ce59c4f892 "Fix SDK build",
52e0838a8f35837a92e7b0277544995e477fe8b6 "sal: fix various clang loplugin
warnings", 3ed325340d14cb28602fb03eb6a46b37cdb8bb99 "[loplugin:unreffun]",
242ccc31d5a2c8be900828523de145e173900514 "Avoid extending the sal UNO API",
3c633a88c5212d8dd665d7bcb9678fa1eac1464f "Stick to sal_uInt32 for
osl_File_OpenFlags", and f4d48ac9cdb822e2c2d3fc1f239fe0958f608cc2 "Fix linking
new CppunitTest_sal_osl_file_details on macOS/Windows".
Co-authored-by: Andras Timar <andras.timar@collabora.com>
Co-authored-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Co-authored-by: Michael Meeks <michael.meeks@collabora.com>
Co-authored-by: Mike Kaganski <mike.kaganski@collabora.com>
Co-authored-by: Miklos Vajna <vmiklos@collabora.com>
Co-authored-by: Szymon Kłos <szymon.klos@collabora.com>
Change-Id: I5220bef367350d8fac8c25d7f40988664b9a8bd5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/187411
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
This helped me to workaround a very mysterious problem, that appeared
in non-debug build (using VS2022 17.14.0 preview 2.0), where a concat
in cppuhelper::ServiceManager::addSingletonContextEntries looking like
"/singletons/" + u"com.sun.star.configuration.theDefaultProvider"_ustr
gave "/single/sincom.sun.star.configuration.theDefaultProvider". The
problem has survived three 'make clean' and rebuild. No idea what was
the reason: maybe a specific VS (preview) version's optimization bug?
Or do we do some spooky memory rewrite somewhere, which happened to
surface in this case? The workaround helping me is obviously because
of some code reorganization in the compiler, not caused by functional
change. (Just for completeness: another workaround was to replace the
literal "/singletons/" with u"/singletons/", which also helped.)
Change-Id: If01823ccafb6b4c44f99f9a39d849d7c425cc069
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183195
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
we already declare the same thing in various places,
and I intend to be using this some more, so it makes
sense to only declare it in one place
Change-Id: Ifea6b589e992dd9f6cd8f2301f837e71397481c8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176046
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
otherwise, the pointer calculations mean that we will start searching
inside data that does not belong to the character array.
which flushes out a couple of problem cases
Change-Id: Ide9edf23900289343077c406d95614057c1d1a6c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173807
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This allows optimizations when 'this' is empty, avoiding allocations, and
making it possible to not special-case it in other places, as was done in
ContentNode::Insert in commit 8ab44b114c
(tdf#161846 avoid allocation in ContentNode::Insert, 2024-07-30).
A couple of disambiguation templated overloads was introduced.
Change-Id: I2b5e94c2175379b2696c34e600393d32731f0ab6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171271
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Replace up-casting conversion constructor with respective conversion operator,
similar to existing css::uno::Reference conversion operator. Thic change will
not allow code like
rtl::Reference<Foo> foo;
rtl::Reference<Foo> bar(foo, uno::UNO_QUERY_THROW);
which was possible because compiler could use temporary css::uno::Reference.
Change-Id: I54b79af3e2508b26e9cd59f2cc7e2ae92f6efbbf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171166
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
This simplifies and deduplicates the code, and even where it was simple,
it has an advantage that if a change in algorithm is decided, it is done
in a single place.
Change-Id: I9ec55a29c5f2b2c972ac81bf07c20fc0a52a2a8b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171033
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
Add new overloads to OUString methods that have a
"OUString* rest" style parameter.
Instead return a view, which does not require allocation.
To avoid overload ambiguity, split the methods into
different variants that do not use default parameters.
Change-Id: I1aa366115750f1f7ea4fe665804195f59f7c4b69
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167632
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Jenkins
Seeing as since:
commit e9531b792d
Date: Tue Feb 6 14:39:47 2024 +0100
sal: rtlRandomPool: require OS random device, abort if not present
Both rtl_random_createPool() and rtl_random_getBytes() first try to get
random data from the OS, via /dev/urandom or rand_s() (documented to
call RtlGenRandom(), see [1]).
we don't use the initial arg to rtl_random_getBytes anymore, drop the
requirement to have one. Then simplify our usages of that, and
addtionally deprecate rtl_random_createPool and rtl_random_destroyPool.
Change-Id: I13dcc067714a8a741a4e8f2bfcf2006373f832c4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167067
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Because I want to make more symbols private, but that runs into a
problem with the special symbol "typeinfo for Foo" which is required for
dynamic_cast.
For clang, we can use SAL_DLLPUBLIC_RTTI to make just that magic
"typeinfo for Foo" symbol visible.
But for gcc, we are left with no option but to make the whole class
visible via <MODULE>_DLLPUBLIC.
(I have a feature request logged against gcc to support something like
that at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113958)
But I also don't want to use <MODULE>_DLLPUBLIC, since that blocks
progress of reducing symbol visibility for platforms other than gcc.
So map SAL_DLLPUBLIC_RTTI to visiblity:default for gcc, which means that
only gcc suffers the negative affects of not having that annotation.
However, that runs into the problem that gcc does not like
visibility:default in a couple of places, so I have to introduce some
extra preprocessor stuff.
Change-Id: Ib4fc5c1d2a1f8cf87d5159a4b5684137ec061605
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164356
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...that is looked for next to the application and, when present, overrides all
the other ways of setting bootstrap variables. LibreOffice itself does not
bring along such a fundamental.override.ini, but it can be convenient for an
administrator to place one in the installation (which can then not be modified
or overridden by end users).
(For convenience, the naming of this ini-file starts to deviate from the old and
rather pointless tradition of naming our ini-files *rc vs. *.ini on different
platforms.)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162187
Tested-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
(cherry picked from commit f4d376e9a10a8c66f7f6ecfe6a1f4763c1927b52)
Conflicts:
sal/rtl/bootstrap.cxx
Change-Id: I057cc67b1af1d806587c3a4dc0bc31c28e79d22b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163251
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Both rtl_random_createPool() and rtl_random_getBytes() first try to get
random data from the OS, via /dev/urandom or rand_s() (documented to
call RtlGenRandom(), see [1]).
In case this does not succeed, there is a fallback to a custom
implementation of a PRNG of unknown design that has never been
substantially changed since initial CVS import, and is presumably not
what would be considered state of the art today, particularly if there's
no actual entropy available to seed it.
Except for a few miscellaneous usages in URE (presumably to avoid
dependencies on non-URE libs), rtlRandomPool is almost always used to
generate material for encryption of documents, which is demanding and
probably beyond what a pure user-space PRNG implementation without
entropy from the OS can provide.
So remove the custom PRNG and instead abort() if reading from the OS
random device fails for whatever reason.
rtl_random_addBytes() becomes a no-op and is therefore deprecated.
Presumably the only kind of environment where random device would be
unavailable in practice is running in some sort of chroot or container
that is missing the device or has incorrect permissions on it; better to
fail hard than to produce encrypted documents of questionable security.
[1] https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/rand-s?view=msvc-170
Change-Id: I3f020c2d11570f8351381d70188ce59bfec9f720
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163056
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
where we have implemented move assignment to take let the compiler take
advantage of any little optimization possibilities that it can take but
where the potential optimization probably doesn't outweigh enforcing
dusting error-prone std::move all over every case where the compiler
doesn't/can't use the move assignment but could.
so convert the myriad of micro optimization warnings into a single
missing move assignment warning which can be then suppressed.
Change-Id: I664193f9a2ac5014cf8d5134105ebd3a36857830
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162494
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
rtl::Reference, uno::Any and rtl::O[U]String
where we have implemented move ctors to take let the compiler take
advantage of any little optimization possibility that it can take
but where the potential optimization probably doesn't outweigh
enforcing dusting error-prone std::move all over every case where
the compiler doesn't/can't use the move ctor but could.
Change-Id: Icf184d96d3278a1740a76c7eb1150e60392351ab
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162337
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
The magic of choosing a substitution font depends on the order of
fontfaces returned from PhysicalFontCollection::GetFontFaceCollection
(called from WinGlyphFallbackSubstititution::FindFontSubstitute).
Since commit db04b3e154 (return 64-bit
hash for O[U]String, 2022-08-22), the order has changed, which
resulted in different fallbacks in some documents (which aren't
well-formed in respect to their formatting, so when they work,
it's just luck).
The difference was because the 64-bit hash implementation was
modelled after Java one. This patch makes the code follow the
algorithm in rtl::str::hashCode_WithLength, used in 32-bit hash,
which restores the order (at least for my system). Not reliable,
just "why not".
Change-Id: I3c482e86bee79d6c9c6981300518c4ff6b7f29d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161706
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
<https://lists.freedesktop.org/archives/libreoffice/2023-November/091151.html>
"CppunitTest_stoc_uriproc failed on Windows" reports that
translateToExternal("file:///abc/%feef") produces an empty string (indicating
failure) instead of "file:///abc/%FEef" (as expected in
stoc/test/uriproc/test_uriproc.cxx) when osl_getThreadTextEncoding() is Shift
JIS.
This was due to how the call to rtl::Uri::encode in
Translator::translateToExternal (in
stoc/source/uriproc/ExternalUriReferenceTranslator.cxx) behaved: It internally
interpreted its input "%FE" as the single-byte Shift JIS character 0xFE. Which
gets mapped to U+2122 as an extension (see "APPLE additions over SJIS, we
convert this like Apple, because I think, this gives better result, then [sic]
we take a replacement char" in sal/textenc/tcvtjp6.tab) in readUcs4, but which
in turn doesn't get mapped back to any Shift JIS character in writeEscapeChar.
Translator::translateToExternal is the only user of
rtl_UriEncodeStrictKeepEscapes, as introduced by
6ff5d3341d "INTEGRATION: CWS c07v013_SRC680
(1.4.40); FILE MERGED: 2007/06/21 13:00:56 sb 1.4.40.1: #b6550116# Made
XExternalUriReferenceTranslator.translateToExternal more robust when the input
URL contains spurious non--UTF-8 octets like %FE (which are now copied verbatim,
instead of signalling error)."
To make the claim true that such "spurious non--UTF-8 octets like %FE" are
always "copied verbatim", regardless of text encoding being used, repurpose
rtl_UriEncodeStrictKeepEscapes to always treat any escape sequences that are
present as (potentially broken) UTF-8.
Change-Id: I0fa0b14d3e3d44e4b5514e1b73c84c407a947ce9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158888
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Andrea Gelmini