summaryrefslogtreecommitdiff
path: root/include/rtl/ustring.h
AgeCommit message (Collapse)AuthorFilesLines
2024-03-05map SAL_DLLPUBLIC_RTTI to visibility:default for gccNoel Grandin1-1/+2
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>
2023-10-27Step 2 of removing cargo-cult pragma pack around rtl_[u]StringStephan Bergmann1-8/+0
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-04-03Fix rtl_(u)str_valueOfBoolean return value documentationMike Kaganski1-2/+2
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>
2022-07-05sal: fix invalid doxygenChris Sherlock1-1/+0
Change-Id: Ib26a695c88d02a0ce5a3c9974fae9f88d8ae89ad Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136783 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-04-11Replace references to rtl_ImplIsWhitespace with implIsWhitespaceMike Kaganski1-1/+1
... after commit 57f22d9b1a4e1cd161a35c8e4c390661db981d2c. Change-Id: I4232adc805593575d0bb7549b40ad35308829261 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132805 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-11-23O[U]String::replaceAt overloads that take string_viewNoel Grandin1-0/+5
which results in lots of nice string_view improvements picked up by the plugins Change-Id: Ib0ec3887816b3d4436d003b739d9814f83e244b2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125657 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-07-21improve the comments of the number conversion functionsNoel Grandin1-3/+2
For the rtl_str_to<NumberType>_WithLength category of functions, the string does not need to be null-terminated Change-Id: I1971c8c10b760743633523e6f680366eafdfc685 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119325 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-02-02tdf#130978 Added comment to all published APImsrijita181-0/+4
Change-Id: I744788bde9778f85ccd9d7667e19d16842900a29 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110248 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-21Relax non-null requirement for some rtl_uString_* functionsStephan Bergmann1-8/+8
...that take a pointer and a length, and where it should be OK that the pointer is null if the length is zero. Those rtl_uString_* functions are targets of OUString member functions that take std::[u16]string_view arguments, and 19926ed35ebb623fc896942b1f232b83edf1fc1e "loplugin:stringview: Flag empty string converted to string view" (which changed some call sites to pass in default- constructed std::[u16]string_view, for which data() returns null) revealed that those rtl_uString_* functions were not prepared for such input. (The guardings of memcpy are necessary because memcpy still requires its pointer arguments to be non-null, even if the corresponding length is zero.) The new sal/qa/rtl/strings/test_strings_defaultstringview.cxx systematically tests all O[U]String[Buffer] member functions taking std::[u16]string_view arguments. It revealed one further issue in IMPL_RTL_STRNAME(compare_WithLength), where UBSan reported a nullptr-with-nonzero-offset > sal/rtl/strtmpl.cxx:149:9: runtime error: applying non-zero offset 18446744073709551614 to null pointer Also, rtl_uString_newReplaceFirstUtf16LUtf16L was found to lack a check for its `from` argument to be non-null. Change-Id: I6a7a712570f7d1e8d52097208c8a43a5a24797af Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106295 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-12Replace remaining uses of sal_CharJulien Nabet1-12/+12
+ remove sal_Char check on compilerplugins Change-Id: I0f7da14e620f0c3d031d038aa8345ba4080fb3e9 Change-Id: Ia6dba4f27b47bc9e0c89159182ad80a5aee17166 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102499 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-05Fix typo in codeAndrea Gelmini1-1/+1
Change-Id: I2934b96c8b2b0a9049d7f238b9c67c8ecf56fa38 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102035 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins
2020-09-04Make many OUString functions take std::u16string_view parametersStephan Bergmann1-0/+35
...instead of having individual overloads for OUString, OUStringLiteral, and literal char16_t const[N]. (The variants taking OUString are still needed for !LIBO_INTERNAL_ONLY, though. The variants taking ASCII-only literal char const[N] are also left in place.) This nicely reduces the number of needed overloads. std::u16string_view allows to pass as arguments: * OUString * OUStringLiteral * OUStringChar (with the necessary conversion added now) * OUStringNumber * u"..." char16_t string literals * u"..."sv std::u16string_view literals * std::u16string, plain char16_t*, and more A notable exceptions is OUStringConcat, which now needs to be wrapped in OUString(...), see the handful of places that needed to be adapted. One caveat is the treatment of embedded NUL characters, as std::u16string_view(u"x\0y") constructs a view of size 1, while only u"x\0y"sv constructs a view of size 3 (which matches the old behavior of overloads for literal char16_t const[N] via the ConstCharArrayDetector<>::TypeUtf16 machinery). See the new checkEmbeddedNul in sal/qa/rtl/strings/test_oustring_stringliterals.cxx. The functions that have been changed are generally those that: * already take a string of determined length, so that using std::u16string_view, which is always constructed with a determined length, is no pessimization (e.g., there are operator == overloads taking plain pointers, which do not need to determine the string length upfront); * could not benefit from the fact that the passed-in argument is an OUString (e.g., the corresponding operator = overload can reuse the passed-in OUString's rtl_uString pData member); * do not run into overload resolution ambiguity issues, like the comparison operators would do. One inconsistency that showed up is that while the original replaceAll(OUString const &, OUString const &, sal_Int32 fromIndex = 0) overload takes an optional third fromIndex argument, the existing replaceAll overloads taking OUStringLiteral and literal char16_t const[N] arguments did not. Fixing that required a new (LIBO_INTERNAL_ONLY) rtl_uString_newReplaceAllFromIndexUtf16LUtf16L (with test code in sal/qa/rtl/strings/test_strings_replace.cxx). Another issue was posed by test code in sal/qa/rtl/strings/test_oustring_stringliterals.cxx that used the RTL_STRING_UNITTEST-only OUString(Except*CharArrayDetector) ctors to verify that certain function calls should not compile (and would compile under RTL_STRING_UNITTEST by taking those Except*CharArrayDetector converted to OUString as arguments). Those problematic "should fail to compile" tests have been converted into a new CompilerTest_sal_rtl_oustring. Change-Id: Id72e8c4cc338258cadad00ddc6ea5b9da2e1f780 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102020 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-31tdf#125688 speed up load of change-tracking ODSNoel Grandin1-0/+25
by 10%, by avoiding an OUString construction in a hot path through XMLTextColumnContext_Impl::XMLTextColumnContext_Impl -> sax::Convert::convertNumber Also changed XMLTextAnimationStepPropertyHdl::importXML to take advantage of the modified convertNumber passing convention. Change-Id: I4e5503dbb094c88a09af8b6dc8c22b6c53f9eb75 Reviewed-on: https://gerrit.libreoffice.org/81726 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-09-24support O(U)String::number() for fast string concatenationLuboš Luňák1-1/+1
When I did the fast string concatenation, I didn't add any support for number(), which simply returned a O(U)String, and so it did the extra allocation/deallocation, although that could be avoided. In order to support this, number() now returns a special temporary return type, similarly to O(U)StringConcat, which allows delaying the concatenation the same way. Also similarly, the change of the return type in some cases requires explicit cast to the actual string type. Usage of OString::getStr() is so extensive in the codebase that I actually added it to the helper class, after that it's only relatively few cases. Change-Id: Iba6e158010e1e458089698c426803052b6f46031 Reviewed-on: https://gerrit.libreoffice.org/78873 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-08-20Fix typosAndrea Gelmini1-1/+1
Change-Id: I88f788b6d8f9363e2f7b5447f6f0b0203f0834f0 Reviewed-on: https://gerrit.libreoffice.org/77758 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2018-08-02[API CHANGE] add some more asserts to the string functionsNoel Grandin1-2/+3
rtl_[u]String_alloc now requires that the length be >= 0. Since this function is only @since Libreoffice 4.1, it is unlikely to be widely used externally. Removed some unit tests that were testing invalid or out of range paramers, which are already not allowed according to the documented contract of those functions. The change in writerfilter is because the new asserts triggered when running testFdo74745 The change in SwTextNode::EraseText is because testFdo60842 triggered the assert in replaceAt. The change in SwFieldSlot::SwFieldSlot is because testMoveRange::Import_Export_Import triggered the assert in replaceAt. The changes in SwFieldSlot::SwFieldSlot and TabControl::ImplGetItemSize are due to failures in the uitests. Change-Id: Ib317261067649b0de96df12873ce31360cd24681 Reviewed-on: https://gerrit.libreoffice.org/58390 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-01-19SAL_W32 is just an alias for _WIN32Stephan Bergmann1-2/+2
...so consistently use the latter instead of the former Change-Id: I144d5e7c472632f93b2258461510346bc85892d9 Reviewed-on: https://gerrit.libreoffice.org/48135 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-12-28Fix typosAndrea Gelmini1-1/+1
Change-Id: I0a8579406a70d2f63d96969c766e2a43d830ed6f Reviewed-on: https://gerrit.libreoffice.org/47114 Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com> Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
2017-10-23loplugin:includeform: UNO API include filesStephan Bergmann1-6/+6
Change these back to consistently use the "..." form to include other UNO API include files, for the benefit of external users of this API. Change-Id: I9c9188e895eb3495e20a71ad44abfa2f6061fa94
2017-08-23tdf#111964: only trim XML whitespaceMike Kaganski1-1/+3
OUString::trim() uses rtl_uString_newTrim, which relies upon rtl_ImplIsWhitespace. The latter treats as whitespaces not only characters with values less than or equal to 32, but also Unicode General Punctuation area Space and some Control characters. Thus, using OUString::trim() is incorrect when the goal is to trim XML whitespace, which is defined as one of 0x09, 0x0A, 0x0D, 0x20. The comments for OUString::trim() and rtl_uString_newTrim are corrected to describe which characters are considered whitespace. A unit test included. Change-Id: I45a132be923a52dcd5a4c35aeecb53d423b49fec Reviewed-on: https://gerrit.libreoffice.org/41444 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
2016-08-29Support ConstCharArrayDetector also for UTF-16 arraysStephan Bergmann1-0/+223
The long-term benefit will be support of C++11 char16_t string literals (for cases of string literals with non-ASCII content) once we drop any compilers that don't support those yet. The short-term benefit is support for an improved OUStringLiteral1 that accepts any sal_Unicode value, not just ASCII ones (see next commit). Change-Id: I3f8f6697d7eb62b5176b7e812b5a5113c53b83a4 Reviewed-on: https://gerrit.libreoffice.org/28445 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2016-01-06tdf#39631 - branch hints: comment, and tweak variously, also use.Michael Meeks1-2/+2
Find a few million mis-predicted branches (according to callgrind) and annotate them. Mark string acquire/release as hot, and a number of deprecated methods as cold. Change-Id: I678b3981794221c97f9ebb70fd0161c0fda5dceb
2015-08-03Fix a copy-paste errorTakeshi Abe1-1/+1
Change-Id: Ifabb905819e32cf4db603f3f7bb18e6cc8fdfdcf
2015-06-26Add optimized OUString += literal overloadStephan Bergmann1-0/+24
Change-Id: Ib34196185f90204a71598f2c659c3fddce7a0e4d
2015-06-23Implement full set of OUString::replaceFirst/All literal overloadsStephan Bergmann1-0/+53
Change-Id: I5f525d91ce24d1d2653a6855f1c4fffc039ae398
2015-01-26Visible function type RTTI for Clang -fsanitize=functionStephan Bergmann1-1/+1
...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
2014-02-18Stick to a single O[U]String hash functionStephan Bergmann1-18/+0
8f8bc0dcf3bc253ae49159d52db049767f476ced "Move string hash function into String class" had introduced a new getHash64 that, besides returning sal_uInt64 instead of just sal_Int32, didn't do sampling of only a handful of characters, but always computed the hash over all characters (as the usage in SfxItemSet and SdPage appears to require for either performance or approximated correctness). However, it would be advantageous to keep the stable URE interface as small as possible. Now, O(1) sampling was apparently considered state of the art when the rtl string classes were first created, closely copying java.lang.String, which at that time demanded sampling for hashCode(), too---but never sampling more than 15 characters, with the obvious (in hindsight, at least) performance catastrophes, so they changed it to O(n) somewhere along the way. Based on that, this commit changes the existing hash functions to not do sampling any more, and removes the newly introduced -64 variants again. (Where the extended value range of sal_uInt64 compared to sal_Int32 was hopefully not vital to the existing uses.) The old implementation used sampling only for strings of length >= 256, so I did a "make check" build with an instrumented hash function that flagged all uses with inputs of length >= 256, and grepped workdir/{Cppunit,Junit,Python}Test for hits. Of the 2849 hits encountered, 2845 where in the range from 256 to 295 characters, and only the remaining four where of 2472 characters. Those four were from CppunitTest_sc_subsequent_filters_test, importing long text into a cell, causing ScDocumentImport::setStringCell to call svl::SharedStringPool::intern, which internally uses an unordered_set. These results appear to justify the change. Change-Id: I78fcc3b0f07389bdf36a21701b95a1ff0a0d970f
2014-02-13Move string hash function into String class.Muthu Subramanian1-0/+18
hashCode() seems to do sampling while creating the hash. hashCode64() will not. Change-Id: Id30f5a2a774cf5244dbc00da9649e95a532484be
2013-11-09fdo#65108 inter-module includes <> include/rtlNorbert Thiebaud1-6/+6
Change-Id: Ic90a365a237aa23846f97131146a5aa2c46b5fd2
2013-10-23fixincludeguards.sh: include - the restThomas Arnhold1-3/+3
Change-Id: If1ee11da444a7f96f2d8668b277540da0bb4dbe9
2013-06-13Introduce O[U]String::toUInt32Stephan Bergmann1-0/+21
...which has become necessary since bd60d41176da540b01d7583cfe00637431967f39 "Handle oveflow in O(U)String::toInt() functions" reduces values in the range (SAL_MAX_INT32 .. SAL_MAX_UINT32] to zero, but some calls of toInt32(16) relied on getting a correct (unsigned) value for the whole input range ["0" .. "FFFFFFFF"] (see libreoffice-4-1 commit 9bf6c83367cedb7be81bf67f30d2147d26c7a8c3 "Revert overflow checks in O[U]String::toInt{32,64} again"). Audited all uses of toInt32/64 with non-decimal radix. (There is still a TODO comment in oox/source/helper/attributelist.cxx, and stoc/source/typeconv/convert.cxx will still need some love and test code.) Change-Id: Iadaca1c0e41dab553687d0ce41c20c10cd657a95
2013-04-24move URE headers to include/David Tardon1-0/+2022
Change-Id: Ib48a12e902f2311c295b2007f08f44dee28f431d Reviewed-on: https://gerrit.libreoffice.org/3499 Reviewed-by: David Tardon <dtardon@redhat.com> Tested-by: David Tardon <dtardon@redhat.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-18 11:21:12 +0000