summaryrefslogtreecommitdiff
path: root/sal
AgeCommit message (Collapse)Author
2021-01-15OUString::matchAsciiL() can be used instead of the fresh startsWithAsciiL()Tor Lillqvist
Revert the addition of the latter. Change-Id: I93636a901cde401b0b7d923e052887f57dd58212 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109315 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2021-01-14Introduce startsWithAsciiL() to match endsWithAsciiL()Tor Lillqvist
Will be used in an upcoming change. Unit test included. Change-Id: I777a755cab543ea277b84fb5ad021d0b91725764 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109264 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2021-01-10fix coverity parse errorsCaolán McNamara
Change-Id: I4884bfb67a061b865e8cf38b2fea6de0cb1bc3d6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109057 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-01-10Missing include guard in new sal/rtl/strtmpl.hxxStephan Bergmann
...as causing trouble in ASan/UBSan builds, > [CXX] jurt/source/pipe/staticsalhack.cxx > In file included from jurt/source/pipe/staticsalhack.cxx:20: > In file included from sal/rtl/ustring.cxx:51: > sal/rtl/strtmpl.hxx:38:28: error: redefinition of 'IMPL_RTL_USTRCODE' > template <typename C> auto IMPL_RTL_USTRCODE(C c) { return std::make_unsigned_t<C>(c); } > ^ > sal/rtl/strtmpl.hxx:38:28: note: previous definition is here > template <typename C> auto IMPL_RTL_USTRCODE(C c) { return std::make_unsigned_t<C>(c); } > ^ [...] Change-Id: Ied38a5f96bbb6d1c0d8ae956629ca6be64dc273f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109055 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-01-10Replace strtmpl.cxx with actual C++ templates in strtmpl.hxxMike Kaganski
This has at least better IDE support, with easier lookup for function implementations. Change-Id: I0e4cfe40df036efa796c057852bd5cb4421507f1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108931 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-12-26New loplugin:stringliteralvarStephan Bergmann
See the comment at the top of compilerplugins/clang/stringliteralvar.cxx for details. (Turned some affected variables in included files into inline variables, to avoid GCC warnings about unused variables.) Change-Id: Ie77219e6adfdaaceaa8b4e590b08971f2f04c83a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108239 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-23Use char16_t string literalsStephan Bergmann
Change-Id: I0a8b577957ac1d4cad5fc1163f244012a8391a77 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108216 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-20Remove the OUString vs. std::u16string_view comparison operators againStephan Bergmann
...that were introduced in e6dfaf9f44f9939abc338c83b3024108431d0f69 "Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uString" to avoid ambiguities, but which is no longer an issue since 46c5de832868d2812448b2caace3eeaa9237b9f6 "make *String(string_view) constructors explicit" Change-Id: I0a7a3fe23412f77fa85fb7e90f04e22f9abd9230 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108044 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-18Check intermediate for not to be rounded value, tdf#138360 follow-upEike Rathke
Change-Id: I98cc25267e7a10c34179bab50d19f49436e1c48c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107929 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@redhat.com>
2020-12-18Replace log2() call with parts.exponent-1023, tdf#138360 follow-upEike Rathke
... to save some cycles as we anyway need only the integer value of the exponent and even exactly this value for the number of possible decimals. Change-Id: I8d462f53cadde6a95d57d1342d8487fbfa001ae9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107928 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@redhat.com>
2020-12-14Add empty OUStringBuffer::toString testStephan Bergmann
...motivated by <https://gerrit.libreoffice.org/c/core/+/107643> "Don't crash on an empty OUStringBuffer::toString" Change-Id: I144f0814f585f56df3fcdc818fd8c5e18ad08115 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107672 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-11Adapt the remaining OUString functions to std string_viewStephan Bergmann
...for LIBO_INTERNAL_ONLY. These had been missed by 1b43cceaea2084a0489db68cd0113508f34b6643 "Make many OUString functions take std::u16string_view parameters" because they did not match the multi-overload pattern that was addressed there, but they nevertheless benefit from being changed just as well (witness e.g. the various resulting changes from copy() to subView()). This showed a conversion from OStringChar to std::string_view to be missing (while the corresponding conversion form OUStringChar to std::u16string_view was already present). The improvement to loplugin:stringadd became necessary to fix > [CPT] compilerplugins/clang/test/stringadd.cxx > error: 'error' diagnostics expected but not seen: > File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 43 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:42): simplify by merging with the preceding assignment [loplugin:stringadd] > File ~/lo/core/compilerplugins/clang/test/stringadd.cxx Line 61 (directive at ~/lo/core/compilerplugins/clang/test/stringadd.cxx:60): simplify by merging with the preceding assignment [loplugin:stringadd] > 2 errors generated. Change-Id: Ie40de0616a66e60e289c1af0ca60aed6f9ecc279 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107602 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-10Avoid calling OString ctor with null pointerStephan Bergmann
...in preparation of potential future changes from using OString to using std::string_view, where OString has an undocumented feature of allowing construction from a null pointer. This is mostly the result of a manual audit of potentially problematic getenv calls across the code base. But there can be other problematic places too, like the xmlGetProp call in tools/source/xml/XmlWalker.cxx. To identify those, rtl_{string,uString}_newFromStr aborts now in non-production debug builds when a null pointer is passed(and all places that hit with a full `make check screenshot` have been addressed here). Once we are confident that all problematic places have been identified, we should drop support for the undocumented feature (see the TODO in sal/rtl/strtmpl.cxx). Change-Id: I595cc6d4f1cda74add2a3db171323f817d362b08 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107430 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-10Do not call GetAddrInfoW if we just want the hostnameSamuel Mehrbrodt
Calling 'gethostname' already gives us the current host name on Windows. For some reason, if that name does not contain a dot, GetAddrInfoW is called, which "provides protocol-independent translation from a Unicode host name to an address". So all this function does, is returning an address for a hostname, while we still only need the hostname and not the address. This causes a lag when creating the lockfile on opening a document if the network is flaky/disabled. See tdf#97931 and tdf#47179 for some problems caused by this. Change-Id: I0c543ea12c23506b2daa50da40bae1a471f6fe16 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107513 Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
2020-12-08Tighten rtl_{string,uString}_newFromStr_WithLength implementationStephan Bergmann
While the documented interface was already narrow (or at least didn't suggest that the length argument could reasonably be negative), the implementation was somewhat broader: For one, it allowed the character pointer to be null even when the length was non-zero, which looks more like a call-site bug than like a useful feature. And for another, while it did assert that the length is non- negative, it nevertheless then checked "overly defensively" for <= 0 rather than == 0 down the road. Change-Id: I084148aaa4b9c4aea16729b0ce90b73ccbe73ebe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107425 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-08Improve a CPPUNIT_ASSERT messageStephan Bergmann
Change-Id: Ia40f249a115a8c4fe01fb384041b4542735166c0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107418 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-07Revert "Fix osl_Security::getHomeDir test under fakeroot"Stephan Bergmann
This reverts commit c8098382da6a7a0448ff8051cac467f91d7e0b36. Conflicts: sal/qa/osl/security/osl_Security.cxx There should be no good reason to run unit tests like CppunitTest_sal_osl_security under fakeroot, esp. not since a58e086ededb8442938e81f971dfae36ef7eb076 "rework the default make target" no longer runs them as part of a plain `make`. (And getting rid of this code means one less place to audit for nullptr issues with getenv in combination with potential OString -> std::string_view changes.) Change-Id: I6bba0ed28ea1ba894ee182f8bda35aad69a54dc6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107336 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-03Better accuracy in rtl_math_approxValue(), tdf#138360 relatedEike Rathke
Similar to commit 5abb1890ffafe5a2212076208a1c6e226f1ffa4e for rtl_math_round() use the reciprocal value in an inverse operation for negative exponents to not use the inexact 1e-1 0.10000000000000001 and so on factors. Change-Id: I05b852e06f2c31d6e0ce622b07277a81a5690833 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107172 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2020-12-03tdf#138360: sal_rtl: Add unittestXisco Fauli
Change-Id: Iac6c4bf09f55446128d7fb7a35b483ca41bc4f00 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107080 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@redhat.com>
2020-12-03Related: tdf#138360 Use approxFloor() in rtl_math_round()Eike Rathke
Ditch mostly but not always working correction value and use approxFloor() instead which yields better results. With this we now have one single place approxValue() in case more fine grained tuning is needed. Unfortunately all numeric spreadsheet function tests use ROUND() in a manner such that they mostly blindly do a ROUND(...;12) regardless of magnitude, sometimes effectively rounding to the 14th significant digit that may fail in cases like for 14.2040730851385 ^ where the constant (rounded) value is stored as is but the calculated value is 14.204073085138471 and the old round() yielded 14.204073085139 for both but the new round() more correctly results in 14.204073085139 and 14.204073085138 so the spreadsheet test case sources had to be changed to ROUND(...;11) in such places. Change-Id: I211bb868a4f4dc9e68f4c7dcc2a187b5e175416f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107135 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2020-12-02Typo in rounded digit string, tdf#138360 follow-upEike Rathke
Change-Id: Ic436d3e9f0c93cb36c5e4377519f2aeb6b7fbd5f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107034 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2020-12-02Related: tdf#138360 Rounding integers to decimals is futileEike Rathke
Change-Id: Ica25747a26d6c2637c46808d1b73aeeed6e1df37 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107001 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2020-11-28Resolves: tdf#138360 better accuracy in rtl_math_round()Eike Rathke
Decimal negative exponents (powers) are imprecise 1e-1 0.10000000000000001 1e-2 0.01 1e-3 0.001 1e-4 0.0001 1e-5 1.0000000000000001e-05 1e-6 9.9999999999999995e-07 1e-7 9.9999999999999995e-08 1e-8 1e-08 1e-9 1.0000000000000001e-09 1e-10 1e-10 1e-11 9.9999999999999994e-12 1e-12 9.9999999999999998e-13 1e-13 1e-13 1e-14 1e-14 1e-15 1.0000000000000001e-15 1e-16 9.9999999999999998e-17 1e-17 1.0000000000000001e-17 1e-18 1.0000000000000001e-18 1e-19 9.9999999999999998e-20 1e-20 9.9999999999999995e-21 so use the positive exponents instead and swap multiplication and division when scaling and scaling back the value, which multiplies the rounded value with a precise integer instead of dividing it by an imprecise fraction. For a large (absolute) value check if it is roundable to the desired decimals at all with the binade's distance precision gap and if not then diminish the decimals parameter. This prevents possible inaccuracies due to overly scaling the value. Change-Id: I41a113078031a552cf98d72f8cb2b10bdc88dea4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106830 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2020-11-28Unit tests for DBL_MAX to string conversion, tdf#136272Eike Rathke
Change-Id: Ied41d1e21fb6e40b54adac3c33fa0d096e25bada Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106783 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2020-11-27Consistently use RTL_CONSTASCII_LENGTH(), tdf#136272 follow-upEike Rathke
The mix with SAL_N_ELEMENTS() was confusing and even wrong in one case. Change-Id: Ife73342b0efc01ed4e76e217d372fc32500c9b2c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106764 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2020-11-27Fix commentEike Rathke
Change-Id: I2ae6e3cadc0f182c4798e5d33b0c7f07fbcbbff6
2020-11-27Resolves: tdf#136272 convert DBL_MAX to 1.7976931348623157e+308Eike Rathke
... and the 4 subsequent nextafters to appropriate strings. An interim workaround to not write the out-of-range string 1.79769313486232e+308 until we have a proper rounding. Change-Id: I5f98a7f0a8e0421fd024a8cc37cc6f3a198d02d1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106717 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@redhat.com>
2020-11-25Related: tdf#136272 accept 1.79769313486232e+308 as DBL_MAXEike Rathke
This does not solve writing the badly rounded value, which still has to be fixed, but at least be able to read/convert it back as double max value. This is not even used in the bug scenario because the "fake" condition in that number format is discarded anyway because it was only written to satisfy ODF, but it helps in case a 1.7976931348623157e+308 value was entered/used on purpose. Change-Id: I413dd93d5a3c4df609fd42a3133d6d82c34afff0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106586 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2020-11-25Silence false loplugin:stringviewparam in conditional code (clang-cl)Stephan Bergmann
Change-Id: Iaa6d36a316f2c474965651e286cff37990f2e817 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106573 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-11-21Relax non-null requirement for some rtl_uString_* functionsStephan Bergmann
...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-11-21tdf#123936 Formatting files in module sal with clang-formatPhilipp Hofer
Change-Id: I04a773e8fd565f57dc0eb887fb4714b6edbb35e0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105699 Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> Tested-by: Jenkins
2020-11-18Replace #if with if constexpr()Mike Kaganski
This allows to test the actual type, not something unrelated Change-Id: I82d0714f6355fc5ae7bd3205af3472a43f1f1051 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105998 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-11-16replace std::max(std::min()) with std::clampNoel
Change-Id: I890d19f5e2177294dc1175c90c98b964347f9e85 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105751 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-11loplugin:stringviewNoel
Add new methods "subView" to O(U)String to return substring views of the underlying data. Add a clang plugin to warn when replacing existing calls to copy() would be better to use subView(). Change-Id: I03a5732431ce60808946f2ce2c923b22845689ca Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105420 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-11disable O(U)String::concat for internal codeNoel Grandin
in favour of the more widely used, and better optimised, operator+ Change-Id: I6a1b37e0f3d253af1f7a0892443f59b620efea63 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105523 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-10-28Extend loplugin:elidestringvar to OStringStephan Bergmann
(In VisitVarDecl, filtering out AbstractConditionalOperator avoids an unhelpful > ~/lo/core/vcl/source/pdf/XmpMetadata.cxx:63:32: error: replace single use of literal 'rtl::OString' variable with a literal [loplugin:elidestringvar] > aXmlWriter.content(sPdfConformance); > ^~~~~~~~~~~~~~~ > ~/lo/core/vcl/source/pdf/XmpMetadata.cxx:52:21: note: literal 'rtl::OString' variable defined here [loplugin:elidestringvar] > OString sPdfConformance = (mnPDF_A == 1) ? "A" : "B"; > ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ) Change-Id: I7d0410f04827d79b4b526752917c37d33cad2671 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104911 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-10-18Limit nDecPlaces to a sensible value [-20, 20]Eike Rathke
Protect against callers using for example rtl_math_StringFormat_F with rtl_math_DecimalPlaces_Max in worst case.. Change-Id: I9f143df6ae67b22e7732547c0f7a53b498caf2b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104472 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2020-10-12Use `pthread_set_name_np` on FreeBSD 12.1 and below, as `pthread_setname_np` ↵Gleb Popov
isn't available there. While here, change the #ifdef check from __FreeBSD_kernel_ to __FreeBSD__, because pthreads API is userspace (read, belongs to libc). Change-Id: I83e76b5502a6dfa1be5d3598eb1367f25815396e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104098 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
2020-10-08Do not redefine ETIME unconditionally on FreeBSD.Gleb Popov
Change-Id: Iee5e7d3e91b6da5eb6c87d8d3547e0cd65742db7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103945 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-10-05loplugin:reducevarscope in salNoel
Change-Id: I2ce95de07b8e0952a1e778e65940b30597396aa6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103949 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-09-26Fix typo in codeAndrea Gelmini
It passed "make check" on Linux Change-Id: I61781bccc365630f15a9baef5224012b0775edbe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103446 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-09-25cppunittester: [_RUN_____] indicates unit test startJustin Luth
-visual: so that the human eye can easily find it -at start: to identify the last test if it ends abruptly -no spaces: easy scripting | grep RUN | awk '{print $2}' A visually unique, eye-catching start banner will be helpful when browsing through logs, or when adding asserts and running a make sw.check. [I frequently look for existing unit tests that match a certain condition in the 15 ooxmlexport tests.] Previously, the tests ran in the order that they existed in the file. So if one asserted/crashed in the middle of the run, you could easily guess which test it was by finding the name of the test that just finished OK. However, since 2f2246d22e2a8ccbc1dc3e6f5243734a61edf270 Author: Stephan Bergmann on Sat Aug 8 12:00:23 2020 external/cppunit: Run tests in deterministic order the tests are sorted by name and run in alphabetical order - which is not at all obvious or intuitive. It certainly makes it harder to guess what the next alphabetical name will be. P.S. For consistency, I considered adding [____DONE_] as well, but existing tooling might search for "finished in:" and grab the first string (the test name) so I don't want to break anything doing that. Change-Id: I5521e681cd9f8304842290680f0389256fe3fe43 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103268 Tested-by: Jenkins Reviewed-by: Justin Luth <justin_luth@sil.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-09-23Silence cid#1467434Stephan Bergmann
Change-Id: Ibb996a3440a272405531c6d3cda0faa1d8c72ec2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103260 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-22OUStringLiteral/OStringLiteral coverity PARSE_ERROR workaroundCaolán McNamara
do more like commit 121771e37f7e2de41cd5643475861062bf25627b Date: Mon Sep 21 09:17:54 2020 +0200 Make some OUStringLiteral vars constexpr cause coverity can live with that Change-Id: I9efd7f848289c4865997a44c6780373068422227 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103147 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-21cppunittester: Do not unload test librariesStephan Bergmann
At least on Windows, e6dfaf9f44f9939abc338c83b3024108431d0f69 "Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uString" caused CppunitTest_sc_tablesheetsobj to fail at exit, when the static OUString aCacheName in ScDocument::GetTable (sc/source/core/data/document.cxx) is destroyed but references constexpr OUStringLiteral gaSrcSheetName(u"SheetToCopy") from test/source/sheet/xspreadsheets2.cxx in Library_subsequenttest, referenced (only) by the CppunitTest_sc_tablesheetsobj library, and both those libraries had already been unloaded from memory. Change-Id: Icea85019611fbaec3603f37b234e9e6fe3502961 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103103 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-16Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uStringStephan Bergmann
...from which an OUString can cheaply be instantiated. This is the OUString equivalent of 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into a consteval'ed, static-refcound rtl_String". Most remarks about that commit apply here too (this commit is just substantially bigger and a bit more complicated because there were so much more uses of OUStringLiteral than of OStringLiteral): The one downside is that OUStringLiteral now needs to be a template abstracting over the string length. But any uses for which that is a problem (e.g., as the element type of a container that would no longer be homogeneous, or in the signature of a function that shall not be turned into a template for one reason or another) can be replaced with std::u16string_view, without loss of efficiency compared to the original OUStringLiteral, and without loss of expressivity. The new OUStringLiteral ctor code would probably not be very efficient if it were ever executed at runtime, but it is intended to be only executed at compile time. Where available, C++20 "consteval" is used to statically ensure that. The intended use of the new OUStringLiteral is in all cases where an object that shall itself not be an OUString (e.g., because it shall be a global static variable for which the OUString ctor/dtor would be detrimental at library load/unload) must be converted to an OUString instance in at least one place. Other string literal abstractions could use std::u16string_view (or just plain char16_t const[N]), but interestingly OUStringLiteral might be more efficient than constexpr std::u16string_view even for such cases, as it should not need any relocations at library load time. For now, no existing uses of OUStringLiteral have been changed to some other abstraction (unless technically necessary as discussed above), and no additional places that would benefit from OUStringLiteral have been changed to use it. Global constexpr OUStringLiteral variables defined in an included file would be somewhat suboptimal, as each translation unit that uses them would create its own, unshared instance. The envisioned solution is to turn them into static data members of some class (and there may be a loplugin coming to find and fix affected places). Another approach that has been taken here in a few cases where such variables were only used in one .cxx anyway is to move their definitions from the .hxx into that one .cxx (in turn causing some files to become empty and get removed completely)---which also silenced some GCC -Werror=unused-variable if a variable from a .hxx was not used in some .cxx including it. To keep individual commits reasonably manageable, some consumers of OUStringLiteral in rtl/ustrbuf.hxx and rtl/ustring.hxx are left in a somewhat odd state for now, where they don't take advantage of OUStringLiteral's equivalence to rtl_uString, but just keep extracting its contents and copy it elsewhere. In follow-up commits, those consumers should be changed appropriately, making them treat OUStringLiteral like an rtl_uString or dropping the OUStringLiteral overload in favor of an existing (and cheap to use now) OUString overload, etc. In a similar vein, comparison operators between OUString and std::u16string_view have been added to the existing plethora of comparison operator overloads. It would be nice to eventually consolidate them, esp. with the overloads taking OUStringLiteral and/or char16_t const[N] string literals, but that appears tricky to get right without introducing new ambiguities. Also, a handful of places across the code base use comparisons between OUString and OUStringNumber, which are now ambiguous (converting the OUStringNumber to either OUString or std::u16string_view). For simplicity, those few places have manually been fixed for now by adding explicit conversion to std::u16string_view. Also some compilerplugins code needed to be adapted, and some of the compilerplugins/test cases have become irrelevant (and have been removed), as the tested code would no longer compile in the first place. sal/qa/rtl/strings/test_oustring_concat.cxx documents a workaround for GCC bug <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96878> "Failed class template argument deduction in unevaluated, parenthesized context". That place, as well as uses of OUStringLiteral in extensions/source/abpilot/fieldmappingimpl.cxx and i18npool/source/localedata/localedata.cxx, which have been replaced with OUString::Concat (and which is arguably a better choice, anyway), also caused failures with at least Clang 5.0.2 (but would not have caused failures with at least recent Clang 12 trunk, so appear to be bugs in Clang that have meanwhile been fixed). Change-Id: I34174462a28f2000cfeb2d219ffd533a767920b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102222 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-12Replace remaining uses of sal_CharJulien Nabet
+ 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-08Fix typos in commentsStephan Bergmann
Change-Id: I8a8108ae970613559a68d996dddcee485ddc052f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102235 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-07Make the OUString ctors taking raw sal_Unicode pointer/non-const array explicitStephan Bergmann
...and in turn add OUString::operator = and OUString::operator += overloads that take a std::u16string_view. Without making the ctors explicit, the operator overloads would have caused ambiguities when called with raw sal_Unicode pointers/non-const arrays, as those can convert to both OUString and to std::u16string_view. But the std::u16string_view operator overloads will generally be useful when changing OUStringLiteral similarly to 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into a consteval'ed, static-refcound rtl_String", at which point many existing uses of OUStringLiteral will be replaced with uses of std::u16string_view. Implementing this change turned up a need for an operator = overload for OUStringNumber, which has thus been added. No such need turned up for a corresponding operator += overload, but which can easily be added when the need arises. It also revealed that the operator == overloads between an OUString and a raw sal_Unicode pointer/non-const array were implemented rather inefficiently, creating a temporary OUString from the raw argument. Those have been improved. Preceding commits have already taken care of many dubious or simply unnecessary implicit uses of the now-explicit OUString ctors. This commit makes explicit the few remaining reasonable uses. (And in some cases needed to change variable initialization syntax from using parentheses to using curly braces, to avoid the most vexing parse issue. And needed to explicitly add OUString ctors from char16 const[2] string literal lvalues in a conditional expression in writerfilter/source/ooxml/OOXMLFastContextHandler.cxx that are only necessary because MSVC apparently still insists on doing array-to-pointer decay there.) All of this only affects LIBO_INTERNAL_ONLY. Change-Id: I7ce31162e9be1c3ff3c0bd184a34b535ec56be9e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102098 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-05Make OUString(char16_t const[N]) ctor check for embedded NULsStephan Bergmann
...and fix the detected fallout. That ctor only started to get used recently with a1570b6052ae9c9349282027c9007b071589bce6 "Make the OUString ConstCharArrayDetector::TypeUtf16 overloads are actually used", but it turns out that that also gave rise to that ctor being picked in error. To better guard against such erroneous uses, make that ctor assert that the given array does not contain embedded NUL characters, see the new sal/qa/rtl/strings/nonconstarray.cxx tests. The one place where that assert would fire during `make check` is fixed now in SwWW8ImplReader::ImportDopTypography. That assert would also fire for tow OUStringLiteral-related tests in the recently added test::oustring::StringLiterals::checkEmbeddedNul, so drop those for how. They cna presumably be added back (with reversed logic values) when OUStringLiteral is changed similarly to how OStringLiteral was changed in 4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into a consteval'ed, static-refcound rtl_String". Change-Id: I6056244003a20f77ba0d953538d25edcbd562211 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102063 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
generated by cgit (git 2.34.1) at 2025-01-10 23:12:49 +0000