summaryrefslogtreecommitdiff
path: root/include/rtl
AgeCommit message (Collapse)Author
2024-05-08drop requirement for rtl_random_getBytes to have "Pool" argCaolán McNamara
Seeing as since: commit e9531b792ddf0cfc2db11713b574c5fc7ae09e2c 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>
2024-04-29WaE: C6326: Potential comparison of a constant with another constantCaolán McNamara
if msvc -analyze is used Change-Id: I5905447a79e8e50d70281e0c230d1ce3b13fc475 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166704 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-03-05map SAL_DLLPUBLIC_RTTI to visibility:default for gccNoel Grandin
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>
2024-02-29Simplify a bitMike Kaganski
Change-Id: I9fbc43916fe0d7af87001e48854a87636115a1f9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164133 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-02-12Introduce a fundamental.override.ini for bootstrap variablesStephan Bergmann
...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>
2024-02-07sal: rtlRandomPool: require OS random device, abort if not presentMichael Stahl
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>
2024-01-24suppress COPY_INSTEAD_OF_MOVE suggestions for rtl::O[U]StringCaolán McNamara
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>
2024-01-20suppress COPY_INSTEAD_OF_MOVE suggestions for uno::ReferenceCaolán McNamara
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>
2024-01-07tdf#159018: make 64-bit hash algorithm similar to 32-bit oneMike Kaganski
The magic of choosing a substitution font depends on the order of fontfaces returned from PhysicalFontCollection::GetFontFaceCollection (called from WinGlyphFallbackSubstititution::FindFontSubstitute). Since commit db04b3e154a1fb8f222232ef969bb3617e051329 (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>
2023-12-04At least VS 2022 Preview 17.9.0 Preview 1.1 needs the fix tooStephan Bergmann
...from 3c6de7e20e35e37cbddd2d35e065525616deac00 "Fix build against VS 2022 17.7.5" Change-Id: I765db22aba2823e6d9a38282ac53e9ba5bcff092 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160309 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2023-11-03Make ExternalReferenceUriTranslator more robust against broken UTF-8Stephan Bergmann
<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 6ff5d3341dbc5df3f0cb5368ccb0e1089338916c "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>
2023-10-27Step 2 of removing cargo-cult pragma pack around rtl_[u]StringStephan Bergmann
see 8ae3ae4bf75fdd0aaa132c956d9da029baa3adc6 "Step 1 of removing cargo-cult pragma pack around rtl_[u]String" Change-Id: Ie9140b92da8895c4991a7f449359bb1747fdb23d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158553 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-19Clean up some C++20 TODOsStephan Bergmann
Change-Id: I8baece4349683c7a83a283b85e24f33874b47ba3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158177 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-18Extend /clr /std:c++20 char8_t workaround to old versions of VS 2022Stephan Bergmann
On IRC, pppregin now reported that she ran into the issue addressed by 3c6de7e20e35e37cbddd2d35e065525616deac00 "Fix build against VS 2022 17.7.5" when using (a presumably old version of) VS 2022. And <https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B#Internal_version_numbering> suggests that older versions of VS 2022 used _MSV_VER values 1930...1936, so cover those too here. Change-Id: Ifee80114c5cd39aeabc31907adafb03eb2f388e9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158122 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-18Clean up the remaining uses of OUStringConstExpr, and drop itStephan Bergmann
Change-Id: I30b2ac77b58e2ae1d1e997a0c830c513542b973d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158101 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-18O[U]String move ctors should be constexpr, tooStephan Bergmann
...similar to 5f2206e3ccf1cf64d2b11b0e5d419973269920a8 "O{U]String copy ctor should be constexpr", which will again be useful for some upcoming replacements of OUStringConstExpr with OUString, and making data actually constexpr. (For example, the static o3tl::enumarray<INetProtocol, SchemeInfo> const map in INetURLObject::getSchemeInfo (tools/source/fsys/urlobj.cxx) can actually be constexpr, but the o3tl::enumarray ctor forwards its SchemeInfo arguments by forwarding references, so uses an implicitly generated constexpr SchemeInfo move ctor, which in turn requires constexpr member move ctors. So when the m_sScheme member will be changed from rtl::OUStringConstExpr to OUString, the OUString move ctor better be constexpr.) Change-Id: Icfc5edbb8422919186517667f876ea90bec1be90 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158099 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-15Drop OStringConstExpr, use constexpr OString insteadStephan Bergmann
Change-Id: Ibb41a27fe7d5456d8db0c98821d5b2acf8586b70 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157949 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-13O{U]String copy ctor should be constexprStephan Bergmann
...similar to the dtors, which will be useful for some upcoming replacements of O[U]StringLiteral and O[U]StringConstExpr Change-Id: Iad905d8466ee76eba1891fbc340073c482d568d5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157944 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-13At least VS 2022 Preview 17.8.0 Preview 3.0 needs the fix tooStephan Bergmann
...from 3c6de7e20e35e37cbddd2d35e065525616deac00 "Fix build against VS 2022 17.7.5" Change-Id: I36a7d02959c5ad04781c3d484966727c3283cbbb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157932 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-12Fix build against VS 2022 17.7.5Stephan Bergmann
After af9c3ed6f748781f2a77e676ffe740992788969b "__cpp_char8_t is generally available now" (which Jenkins built successfully against some VS 2019 version), various people using at least exactly VS 2022 17.7.5 (--with-visual-studio=2022) started to experience issues like > include\rtl/stringutils.hxx(251): error C2065: 'char8_t': undeclared identifier when compiling e.g. cli_ure/source/climaker/climaker_app.cxx (i.e., in /clr mode). This is similar to the VS 2019 16.11.30 /clr issue discussed in the commit message of 5a40abc86b94c0be5b4a252c6ab5b0b0df6e520d "Drop some newly obsolete __cplusplus version checks", just that it apparently hits with a different set of VS versions. The fix here is similar to the fix there, just conditionally disable char8_t functionality for certain VS versions in /clr mode, and keep fingers crossed. Change-Id: I8c4ed2e3d290dc1c94f329d314407a56170564f5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157866 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-11__cpp_lib_char8_t is generally available nowStephan Bergmann
...after 1eef07805021b7ca26a1a8894809b6d995747ba1 "Bump baseline to C++20" Change-Id: I45aa7538174a0c62ad5a4871e2914b30580546c0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157827 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-11The other OStringLiteral ctor should be non-explicit tooStephan Bergmann
It had been missed by 31cd6fd0f3c856a81a03d0229de1c4d10442844f "Make OStringLiteral ctor non-explicit", and now prevented u8"..."_ostr from compiling. Change-Id: Ifb214fba0957b0d26b11daae6190ffa9d21713f0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157823 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-11__cpp_char8_t is generally available nowStephan Bergmann
...after 1eef07805021b7ca26a1a8894809b6d995747ba1 "Bump baseline to C++20" Change-Id: I75509f3731357e0e3ae73c3774abd6e4070f605b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157806 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-11Delete OUString UTF-16 string literal ctor/assignment opStephan Bergmann
...that have been made unused by 7ef3d937415185ef66e32dd3043783eddcd03db5 "loplugin:ostr: Rewrite some uses of O[U]String to use ""_ostr/u""_ustr literals". (And which means we can remove the relevant code from that plugin again.) (This also found a handful of remaining uses that had been hard for the plugin to discover, along the lines of > std::map<OUString, int> m = {{u"foo", 0}}; being represented by a > DeclStmt 0xdaca578 <line:103:5, col:50> > `-VarDecl 0xdac9150 <col:5, col:49> col:29 s11 'std::map<OUString, int>':'std::map<rtl::OUString, int>' cinit destroyed > `-ExprWithCleanups 0xdaca548 <col:35, col:49> 'std::map<OUString, int>':'std::map<rtl::OUString, int>' > `-CXXConstructExpr 0xdaca508 <col:35, col:49> 'std::map<OUString, int>':'std::map<rtl::OUString, int>' 'void (initializer_list<value_type>, const std::less<rtl::OUString> &, const allocator_type &)' list std::initializer_list > |-CXXStdInitializerListExpr 0xdaca480 <col:35, col:49> 'initializer_list<value_type>':'std::initializer_list<std::pair<const rtl::OUString, int>>' > | `-MaterializeTemporaryExpr 0xdaca468 <col:35, col:49> 'const std::pair<const rtl::OUString, int>[1]' xvalue > | `-CXXBindTemporaryExpr 0xdaca448 <col:35, col:49> 'const std::pair<const rtl::OUString, int>[1]' (CXXTemporary 0xdaca448) > | `-InitListExpr 0xdac9df0 <col:35, col:49> 'const std::pair<const rtl::OUString, int>[1]' > | `-CXXConstructExpr 0xdaca408 <col:36, col:48> 'const std::pair<const rtl::OUString, int>' 'void (const char16_t (&)[4], int &&) noexcept(_S_nothrow_constructible<const char16_t (&)[4], int>())' list > | |-StringLiteral 0xdac91b8 <col:38> 'const char16_t[4]' lvalue u"foo" > | `-MaterializeTemporaryExpr 0xdaca3f0 <col:46> 'int' xvalue > | `-IntegerLiteral 0xdac91d8 <col:46> 'int' 0 > |-CXXDefaultArgExpr 0xdaca498 <<invalid sloc>> 'const std::less<rtl::OUString>':'const std::less<rtl::OUString>' lvalue > `-CXXDefaultArgExpr 0xdaca4b8 <<invalid sloc>> 'const allocator_type':'const std::allocator<std::pair<const rtl::OUString, int>>' lvalue Clang AST.) Change-Id: I496fe9d4d5e1a033cb7b27b4e04b303f8ddbed4a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157756 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-09-29Drop some newly obsolete __cplusplus version checksStephan Bergmann
...after 1eef07805021b7ca26a1a8894809b6d995747ba1 "Bump baseline to C++20". Which revealed that at least for VS 2019 16.11.30 (but not for at least VS 2022 17.7.4), in /clr mode (e.g., when compiling cli_ure/source/climaker/climaker_app.cxx), the -std:c++20 is effectively ignored, and compilation of such source files failed with > include\rtl/string.hxx(191): error C2955: 'rtl::OStringLiteral': use of class template requires template argument list > include\rtl/string.hxx(88): note: see declaration of 'rtl::OStringLiteral' > include\rtl/string.hxx(191): error C7592: a non-type template-parameter of type 'rtl::OStringLiteral' requires at least '/std:c++20' > include\rtl/string.hxx(397): error C2955: 'rtl::OStringLiteral': use of class template requires template argument list > include\rtl/string.hxx(88): note: see declaration of 'rtl::OStringLiteral' etc. To work around that, keep the 27d1f3ac016d77d3c907cebedca558308f366855 "O[U]String literals (unusable for now, C++20 only)" functionality disabled when compiling /clr sources (i.e., where _MANAGED is defined) for that old compiler. Change-Id: If62ceef5f8e55a828b880f197111fe387e4953fe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157205 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-09-15StringHolder detour is only really needed for ""_tstrStephan Bergmann
Change-Id: Ifd3b21cdfa3738737b47fde0d014c312494227e3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156933 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-07-31Introduce "..."_tstr as a companion to "..."_ostr/u"..."_ustr in template codeStephan Bergmann
...like > *path = "/"; in > template<typename T> oslFileError getSystemPathFromFileUrl( > OUString const & url, T * path, bool resolveHome) in sal/osl/unx/file_url.cxx, where T is either OString or OUString. That can now be replaced with > *path = "/"_tstr; and for OString it will be a no-cost constexpr operation, while for OUString it will still construct the OUString instance at runtime (as did the original code for both OString and OUString). (This change required moving the definition of rtl::detail::OStringHolder around in include/rtl/string.hxx. For consistency, I similarly moved around the definition of rtl::detail::OUStringHolder in include/rtl/ustring.hxx, too.) Change-Id: I7fb3a81b438f98c609684f7e70b7a60068d32fdb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154748 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-07-19Work around MSVC bug with "..."_ostr vs. u"..."_ostrStephan Bergmann
Since 27d1f3ac016d77d3c907cebedca558308f366855 "O[U]String literals (unusable for now, C++20 only)", <https://developercommunity.visualstudio.com/t/Using-same-string-literal-suffix-for-cha/10416970> "Using same string literal suffix for char and char16_t string overloads causes 'no matching overloaded function found'" caused --with-latest-c++ builds to fail with > sal/qa/rtl/strings/test_oustring_stringliterals.cxx(432): error C2672: '""_ostr': no matching overloaded function found > include\rtl/ustring.hxx(3604): note: could be 'rtlunittest::OUString operator ""_ostr(void)' > include\rtl/string.hxx(2402): note: or 'rtlunittest::OString operator ""_ostr(void)' > sal/qa/rtl/strings/test_oustring_stringliterals.cxx(432): error C2672: 'CppUnit::assertEquals': no matching overloaded function found > workdir\UnpackedTarball\cppunit\include\cppunit/TestAssert.h(161): note: could be 'void CppUnit::assertEquals(const T &,const T &,CppUnit::SourceLine,const std::string &)' > sal/qa/rtl/strings/test_oustring_stringliterals.cxx(432): note: 'void CppUnit::assertEquals(const T &,const T &,CppUnit::SourceLine,const std::string &)': expects 4 arguments - 3 provided etc. So help MSVC along by renaming from u"..."_ostr to u"..."_ustr for now. Change-Id: Iad401f0681ac9326b7c57259c5483263ddfbfd4e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154634 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-07-14O[U]String literals (unusable for now, C++20 only)Stephan Bergmann
Change-Id: I0ecd1a8b60a01aefdf0139e3777dc006532764fd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154434 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-07-13Restrict deleted catch-all O[U]StringChar ctor to arithmetic/enum typesStephan Bergmann
...which should still cover the issues that 7320d7a4a4dd0657f2d650a6f580ad399529f0f1 "OUStringChar must either take a sal_Unicode or an ASCII char" wanted to address, but without causing ambiguities where some unrelated type would unexpectedly be sucked into a conversion chain going through these ctors Change-Id: Iee3769dc6af5d7a1c8540a548bc2e10a89e637da Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154391 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-05-27Unify Concat2ViewMike Kaganski
Change-Id: Idb0a0fc620ece33e7ed6bcec3cbd8a0a833b1e38 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152314 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-05-06Simplify O(U)StringBuffer's append - delegate to insertMike Kaganski
This limits the number of places that know how to deal with a given type. O(U)StringNumber doesn't need an own overload, because it has operator basic_string_view. Change-Id: I6e82dc2cef103b578153fbc3ce16e96247ea9d74 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151379 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-05-06Optimize O(U)StringBuffer's append/insert taking float/doubleMike Kaganski
rtl_(u)str_valueOf(Float/Double) are the most inefficient choice: their implementations call rtl_math_doubleTo(U)String, asking to allocate a new rtl_(u)String; then copy the string to the provided buffer on stack, and destroy the rtl_(u)String; and then copy the buffer into self. Even using O(U)String::number() would be more efficient, avoiding the intermediate stack buffer copy. But rtl_math_doubleTo(U)String can take also the O(U)StringBuffer's data directly, allowing to insert efficiently. Use that. Change-Id: I720ea7be6f4b2b92865a18eafcdb9ca9a089b854 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151377 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-05-06[API CHANGE] Fix O(U)StringBuffer::insert taking floatMike Kaganski
It was broken from the start: it was introduced like this already in commit 9399c662f36c385b0c705eb34e636a9aec450282 (initial import, 2000-09-18). Creating a temporary copy as a return value makes no sense. Change-Id: I6910d426c2437038ec4979be2c44cd72146dec9c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151375 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins
2023-04-12Use more *string_viewMike Kaganski
OUString::equalsIgnoreAsciiCaseAscii and compareToIgnoreAsciiCaseAscii taking string_view are added as overloads, rather than replacements to the variants taking const char*, because the latter have benefit when the passed C-style string's length is unknown, because these variants don't pre-calculate the length. Change-Id: I2def689d7b7784212dc6cd6b8ae9ab1d42604079 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150272 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-04-10Use of O(U)StringNumber for float/double is actually a pessimisationMike Kaganski
They use rtl_(u)str_valueOf(Float|Double), to fill the buffer, and the latter use doubleToString, which creates an rtl_(u)String, copies to the buffer, and releases the rtl_(u)String. So instead just use the rtl_(u)String from rtl_math_doubleTo(U)String directly. Even when the end result is not needed as O(U)String, this would avoid an extra copy step. Also, this avoids separate LIBO_INTERNAL_ONLY implementations. Change-Id: Ib1d9ecebd7876dfff7dc758f89ee4c1536647a50 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150150 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-04-05Simplify O(U)String::number implementationMike Kaganski
Change-Id: I059f0324597a90aee01c95170a48ac5578f3caee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150037 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-04-04Make O(U)String::boolean also return an O(U)StringNumberMike Kaganski
Change-Id: I184fa0e4e45662e0fac86076d1c8733a0465bb56 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149978 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-04-03Fix rtl_(u)str_valueOfBoolean return value documentationMike Kaganski
The reported numbers are factually wrong. See rtl::str::valueOfBoolean, and back to commit cb6ab44fbef0a71984a15766d5ad7dcbe0a82a10 (template implementation for String/UString, 2001-03-16) that introduced the actual return values. Change-Id: Ib692ee7164be31bde3d884823a77e6452dbf9cb7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149890 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-03-29Prevent accidental OUString(nullptr)Mike Kaganski
Similar to commit f20162304d73bc01955e9ef6506c3bd1c7016c48 (Rule out OString(std::nullptr_t), 2015-07-12); after that, OUString was changed to have only one ctor taking pointer in LIBO_INTERNAL_ONLY case, so became a similar issue. Change-Id: Iac851d1c24c0616ee52a112b81ba71877c28c493 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149696 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-03-28Fix build for recent GCCStephan Bergmann
...after 58dd5870a77344754ea459d8423d1b3787a6a813 "Avoid dangling references to temporary O[U]StringConcatMarker instances" caused e.g. > In file included from /home/tdf/lode/jenkins/workspace/lo_callgrind_linux/include/rtl/string.hxx:49, > from /home/tdf/lode/jenkins/workspace/lo_callgrind_linux/include/rtl/ustring.hxx:43, > from /home/tdf/lode/jenkins/workspace/lo_callgrind_linux/include/osl/module.hxx:31, > from /home/tdf/lode/jenkins/workspace/lo_callgrind_linux/sal/osl/all/loadmodulerelative.cxx:26: > /home/tdf/lode/jenkins/workspace/lo_callgrind_linux/include/rtl/stringconcat.hxx:468:8: error: partial specialization ‘struct rtl::StringConcat<C, rtl::StringConcatMarker<C>, T2, Dummy>’ is not more specialized than [-fpermissive] > 468 | struct StringConcat<C, StringConcatMarker<C>, T2, Dummy> > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > /home/tdf/lode/jenkins/workspace/lo_callgrind_linux/include/rtl/stringconcat.hxx:190:8: note: primary template ‘template<class C, class T1, class T2, typename std::enable_if<(allowStringConcat<C, T1> && allowStringConcat<C, T2>), int>::type <anonymous> > struct rtl::StringConcat’ > 190 | struct StringConcat > | ^~~~~~~~~~~~ (<https://ci.libreoffice.org/job/lo_callgrind_linux/13174/>) with GCC 11.02. (But what fixes it for recent versions of GCC would start to fail with > In file included from sal/osl/all/loadmodulerelative.cxx:26: > In file included from include/osl/module.hxx:31: > In file included from include/rtl/ustring.hxx:43: > In file included from include/rtl/string.hxx:49: > include/rtl/stringconcat.hxx:468:8: error: non-type template argument specializes a template parameter with dependent type 'std::enable_if_t<allowStringConcat<C, T1> && allowStringConcat<C, T2>, int>' (aka 'typename enable_if<allowStringConcat<C, T1> && allowStringConcat<C, T2>, int>::type') > struct StringConcat<C, StringConcatMarker<C>, T2> > ^ > include/rtl/stringconcat.hxx:189:125: note: template parameter is declared here > template <typename C, typename T1, typename T2, std::enable_if_t<allowStringConcat<C, T1> && allowStringConcat<C, T2>, int> = 0 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ for e.g. Clang 17 trunk.) Change-Id: I6110d5a2813b561748654065e76bb4b6ab2f82d8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149644 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-03-27Avoid dangling references to temporary O[U]StringConcatMarker instancesStephan Bergmann
...which were created in O[U]String::Concat and bound to O[U]StringConcat::left. Thanks to Mike Kaganski for finding this. Change-Id: Id7838bc55eec7cba8860c2ec21a247bf4abd3c62 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149629 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-03-17Towards literal O[U]String types in C++20Stephan Bergmann
...(where destructors can be constexpr), making 21584b304b21bfe6b99b6f29018c6b754ea28fc0 "make OUString(OUStringLiteral) constructor constexpr" and 983c1146ac80c038feae653e8e3752a72171d6cb "actually make OString(OStringLiteral) constructor constexpr" actually useful and eventually removing the need for O[U]StringConstExpr again Change-Id: I55520c1d928758f61e92336206e0f14b6f12a711 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148978 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-03-13Introduce OUStringBuffer::insert taking OUStringConcatMike Kaganski
Avoids some (re)allocations, and aligns with already existing append Change-Id: I536ba50f56fc560c0f6e8c0a8b65bd4248896a8e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148777 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-02-13These const_casts are unneededMike Kaganski
Change-Id: I4b1d81665f9bfeb040530bac6bafa3ee2c85782f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146849 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-01-24Be consistent in checks for LIBO_INTERNAL_ONLYTor Lillqvist
Only check whether LIBO_INTERNAL_ONLY is defined or not. Don't check its value. If undefined, its value will default to 0, but checking the value will cause a warning that will be treated as an error if you compile with -Werror, as you should. Change-Id: I1d9e4569a016d2e6dbaa9d612071a5528ff1902e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146066 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2022-11-28tdf#133343 improve perf of OUString::operator=(&&)Noel Grandin
shaves 4% off the save time here. We don't need to do this - either the old rtl_uString will be overwritten in the source object, or it will be destructed, either way, re-initialising it is a waste of time. Change-Id: I47becb17de1e47f2a26c2ac4497e769e13523115 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143403 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-11-08A better fix for C++23 P2266R1Stephan Bergmann
After 6d6a143913603b040c10a5db83c2103557899011 "Address some of the sprintf in vcl/source/fontsubset/cff.cxx", --with-latest-c++ builds that pick up a C++23 compiler that implements <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2266r1.html> "P2266R1: Simpler implicit move" started to fail with something like > vcl/source/fontsubset/cff.cxx:2061:16: error: no viable conversion from returned value of type 'char[64]' to function return type 'OString' > return aDefaultGlyphName; > ^~~~~~~~~~~~~~~~~ [...] > include/rtl/string.hxx:313:5: note: candidate constructor [with T = char[64]] not viable: expects an lvalue for 1st argument > OString( T& value, typename libreoffice_internal::NonConstCharArrayDetector< T, libreoffice_internal::Dummy >::Type = libreoffice_internal::Dummy() ) > ^ etc. So I figured there should be something better than 433ab39b2175bdadb4916373cd2dc8e1aabc08a5 "Adapt implicit OString return value construction to C++23 P2266R1" (which this commit reverts, modulo its conflicts in comphelper/source/xml/xmltools.cxx and sc/source/filter/xcl97/XclExpChangeTrack.cxx) to address the underlying issue in a way that keeps code that works up to C++20 also working in C++23. (The fix is only relevant for non-explicit constructors that involve NonConstCharArrayDetector and non-const lvalue references, not for other functions involving those. OUString has a similar constructor but which is explicit, and OUStringBuffer doesn't have any similar constructors at all, so this only affects OString and OStringBuffer constructors.) Change-Id: I31cf16b9507899f5999243f8467dfa24bc94c5ac Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142455 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-11-08Address some of the sprintf in vcl/source/fontsubset/cff.cxxStephan Bergmann
...(which cause -Werror,-Wdeprecated-declarations with macOS 13 SDK), by making CffSubsetterContext::getString, and in turn CffSubsetterContext::getGlyphName, return OString. Which in turn required adding rtl::OStringConstExpr and OString::unacquired counterparts of rtl/ustring.hxx functionality to rtl/string.hxx. (It's not quite clear to me whether the nMaxLen clipping in CffSubsetterContext::getString was only there to avoid overflow of the-- somewhat arbitrarily sized?---static aNameBuf, so could go now, or rather served as a more general safety measure to not read past the mpReadPtr buffer end and should thus remain. Hence, I added a TODO comment for now.) Change-Id: I473d5a54a4be5b02917e197391e4f0982dcf690c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142412 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-11-08Avoid an explicit static_castStephan Bergmann
...when shoehorning a std::size_t value into sal_Int32, to not suppress potential warnings from tools like -fsanitize=implicit-signed-integer-truncation and -fsanitize=implicit-integer-sign-change Change-Id: I610410f7cd69769c3721b2019e16b4c9f214ad81 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142407 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
generated by cgit (git 2.34.1) at 2025-01-24 02:32:06 +0000