summaryrefslogtreecommitdiff
path: root/include/o3tl
AgeCommit message (Collapse)Author
2024-10-14version COVERITY conditionalsCaolán McNamara
so there's a recheck on each major if they are still needed Change-Id: I351f731fe4eaec0ebf735147a9a168cccba3bca5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174883 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-09-25Confine a hack to known-broken --enable-pchStephan Bergmann
The hack was introduced in 7db1150b2c4a9adb993084d2dceedb450781b1dc "fix macos build with clang 16". (And for our --enable-pch for Clang being known-broken, also see ffc1ab15ae358315516aab319778a254688afbd3 "Work around some Clang PCH consteval issue by disabling HAVE_CPP_CONSTEVAL".) Change-Id: I5dcd7f96ba39bf4d0748940778699cb7d368f449 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173891 Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-09-19fix macos build with clang 16Noel Grandin
Undefined symbols for architecture arm64: "o3tl::strong_int<unsigned short, LanguageTypeTag>::strong_int<int>(int, std::__1::enable_if<std::is_integral<int>::value, int>::type)", referenced from: sfx2::(anonymous namespace)::SvxInternalLink::Connect(sfx2::SvBaseLink*) in linkmgr2.o SfxHTMLParser::GetTableDataOptionsValNum(unsigned int&, o3tl::strong_int<unsigned short, LanguageTypeTag>&, rtl::OUString const&, std::__1::basic_string_view<char16_t, std::__1::char_traits<char16_t>>, SvNumberFormatter&) in sfxhtml.o SfxHTMLParser::GetTableDataOptionsValNum(unsigned int&, o3tl::strong_int<unsigned short, LanguageTypeTag>&, rtl::OUString const&, std::__1::basic_string_view<char16_t, std::__1::char_traits<char16_t>>, SvNumberFormatter&) in sfxhtml.o SfxHTMLParser::GetTableDataOptionsValNum(unsigned int&, o3tl::strong_int<unsigned short, LanguageTypeTag>&, rtl::OUString const&, std::__1::basic_string_view<char16_t, std::__1::char_traits<char16_t>>, SvNumberFormatter&) in sfxhtml.o SfxHTMLParser::GetTableDataOptionsValNum(unsigned int&, o3tl::strong_int<unsigned short, LanguageTypeTag>&, rtl::OUString const&, std::__1::basic_string_view<char16_t, std::__1::char_traits<char16_t>>, SvNumberFormatter&) in sfxhtml.o ld: symbol(s) not found for architecture arm64 clang++: error: linker command failed with exit code 1 (use -v to see invocation) make[1]: *** [/Users/noelgrandin/lode/dev/core/sfx2/Library_sfx.mk:20: /Users/noelgrandin/lode/dev/core/instdir/LibreOfficeDev.app/Contents/Frameworks/libsfxlo.dylib] Error 1 make[1]: Target 'build' not remade because of errors. make: *** [Makefile:296: build] Error 2 Change-Id: Ia8c338a89156e18a1c96630ecad2bccbba7bb745 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173652 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-09-09Improve run-time Currency type support in BasicMike Kaganski
Change-Id: I1e04c6022944034a30ef896b8cd24050ebe3bbd5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173042 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-09-08Add a comment about possible use of standard functions, when/if availableMike Kaganski
Change-Id: Ia5c217c7388c1f8198cfb09fb5733c1ab08bc12f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173043 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-08-25cid#1608296 silence Overflowed integer argumentCaolán McNamara
and cid#1606815 Overflowed integer argument cid#1606617 Overflowed integer argument Change-Id: I4569190edd9b8d65e9b080a7ad0fac391f4a657e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172348 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-07-17Use IsRunningUnitTest / IsRunningUITest consistentlyMike Kaganski
The functions are moved to o3tl as inline functions. Change-Id: Ief7d7e292ef15e055ad04ab5707e5e6a2a05b916 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170636 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-07-09tsan: fix data race in o3tl::cow_wrapperNoel Grandin
where the use_count() call was happening without any kind of synchronisation - switch to use std::atomic which does the right thing for us Change-Id: I79a6452f42bd425ea494bb0298dc134de5678813 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170217 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-04-28Extended loplugin:ostr manual changesStephan Bergmann
I had done these a while ago, when I looked into extending loplugin:ostr to do more automatic rewriting, and these were places where I needed to do something manually, for one reason or another, because the automatic rewriting would not pick it up correctly. However, I got distracted, and a wholesale automatic rewrite would still run into cases where an _ostr/_ustr instance from a library's .rodata would still be referenced after the library has already been dlcose'd. So I never came around to finishing all that. But there appears to be renewed interest in (automatic) rewritings here now, so it probably makes sense if I share this part of my work anyway. Change-Id: I3da9d38398e4bca373cb0000a9d34b49a36ad58a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166792 Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de> Tested-by: Jenkins
2024-03-25tdf#157665 Use <=> operator for errcode and strong_intRMZeroFour
As part of the efforts in #157665 concerning the spaceship operator for the C++20 codebase upgrade, this commit implements the spaceship operator, replacing redundant operator overloads, in strong_int.hxx and errcode.hxx Change-Id: I23985207c27d6a5147c3f7b4a0d2416f86dec5b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165219 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-03-09Support o3tl::iterateCodePoints with both sal_Int32 and std::size_tStephan Bergmann
...and clean up the most gross casting offenses Change-Id: If0d646fb3e73e71a9a2735569395034973563a1f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164602 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-02-17Generalize search algorithms in sorted_vectorMike Kaganski
This allows to simplify the code somewhat, and also to relax requirements to the arguments, e.g. allowing to pass const objects to search in vector containing non-const objects. Change-Id: Id34911a8694bbdec275d22b51ca4a0845c9fa4c4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163519 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-02-08A better approximation of std::strong_orderStephan Bergmann
(Unfortunately, the environments that don't have std::strong_order typically also don't have std::bit_cast, so we need to approximate that, too.) Change-Id: I0b6344c83bc8227af090cfe68902acd385f682ff Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163111 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-02-07double operator < is not a strict weak ordering due to NaNStephan Bergmann
...so recent LLVM 19 trunk libc++ in debug mode complained during CppunitTest_chart2_export2 about > ~/llvm/inst/bin/../include/c++/v1/__debug_utils/strict_weak_ordering_check.h:59: assertion __comp(*(__first + __a), *(__first + __b)) failed: Your comparator is not a valid strict-weak ordering at > 5 libsystem_c.dylib 0x0000000183279a40 abort + 180 > 6 libc++.1.0.dylib 0x00000001030f9d98 _ZNSt3__123__cxx_atomic_notify_oneEPVKv + 0 > 7 libchartcorelo.dylib 0x00000002f817f0ec _ZNSt3__135__check_strict_weak_ordering_sortedB8de190000INS_11__wrap_iterIPNS_6vectorIdNS_9allocatorIdEEEEEEN5chart12_GLOBAL__N_116lcl_LessXOfPointEEEvT_SB_RT0_ + 960 > 8 libchartcorelo.dylib 0x00000002f817e6cc _ZNSt3__118__stable_sort_implB8de190000INS_17_ClassicAlgPolicyENS_11__wrap_iterIPNS_6vectorIdNS_9allocatorIdEEEEEEN5chart12_GLOBAL__N_116lcl_LessXOfPointEEEvT0_SC_RT1_ + 268 > 9 libchartcorelo.dylib 0x00000002f8172a90 _ZNSt3__111stable_sortB8de190000INS_11__wrap_iterIPNS_6vectorIdNS_9allocatorIdEEEEEEN5chart12_GLOBAL__N_116lcl_LessXOfPointEEEvT_SB_T0_ + 68 > 10 libchartcorelo.dylib 0x00000002f8172820 _ZN5chart11VDataSeries15doSortByXValuesEv + 508 > 11 libchartcorelo.dylib 0x00000002f8064c44 _ZN5chart9AreaChart12createShapesEv + 1528 > 12 libchartcorelo.dylib 0x00000002f80f2ae0 _ZN5chart9ChartView28impl_createDiagramAndContentERKNS_18CreateShapeParam2DERKN3com3sun4star3awt4SizeE + 4440 > 13 libchartcorelo.dylib 0x00000002f80f77ac _ZN5chart9ChartView14createShapes2DERKN3com3sun4star3awt4SizeE + 2728 > 14 libchartcorelo.dylib 0x00000002f80f58ec _ZN5chart9ChartView12createShapesEv + 692 > 15 libchartcorelo.dylib 0x00000002f80f4598 _ZN5chart9ChartView15impl_updateViewEb + 288 But the introduced use of `std::strong_order(first[0], second[0]) < 0` then triggered a false > lo/core/chart2/source/view/main/VDataSeries.cxx:105:61: error: NullToMemberPointer ValueDependentIsNotNull ZeroLiteral -> nullptr [loplugin:nullptr] > 105 | return std::strong_order(first[0], second[0]) < 0; > | ^ so needed some hack in loplugin:nullptr. And old versions of libc++, still used at least on Android, do not have any implementations of std::strong_order. So detect those cases in configure.ac (checking for std::strong_order for double, which is what is actually being used in the code) and fall back to operator <=> for now, even if that will not provide a strict weak ordering and will thus continue to violate the requirements of std::sort. And then our venerable clang-format 5.0.0 would have broken the token `<=>` into `<= >`, so exclude include/o3tl/compare.hxx from its mis-treatment. Change-Id: I7a64a630eb5f560dce59f3ff9d51ca3d1adc70be Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163075 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2023-12-21std::list::size() can still be implemented as std::distance()Caolán McNamara
seen with Red Hat Developer Toolset 10 https: //github.com/CollaboraOnline/online/issues/6893#issuecomment-1866342284 Change-Id: I4a0e8ad028126dded678e971a6261d6725a6b06c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161129 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-12-01tdf#158442: fix opening hybrid PDFs on WindowsMike Kaganski
Commit 046e9545956d8ad1d69345d6b4a4c0a33714d179 (Try to revert to use of file_iterator from boost on Windows, 2023-10-31) had introduced a problem that pdfparse::PDFReader::read couldn't create file_iterator for files already opened with write access: mmap_file_iterator ctor on Windows used single FILE_SHARE_READ as dwSharedMode parameter for CreateFileA WinAPI; and that failed, when the file was already opened using GENERIC_WRITE in dwDesiredAccess - which happens when opening stream in TypeDetection::impl_detectTypeFlatAndDeep. Fix this by patching boosts' mmap_file_iterator constructor to use FILE_SHARE_READ | FILE_SHARE_WRITE, like we do in osl_openFile. But there was a pre-existing problem of using char-based CreateFileA API, which disallows opening any files with names not representable in current Windows codepage. Such hybrid PDF files would still fail creation of the file_iterator, and open as PDF. Fix that by further patching boost to have wstring-based constructors for file_iterator and mmap_file_iterator on Windows, which would call CreateFileW. Change-Id: Ib190bc090636159ade390b3dd120957d06d7b89b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160218 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-10-27Clarify that o3tl::cmp_* is still needed for LLVM 12 libc++ for nowStephan Bergmann
...which is apparently used by Android builds, so <https://gerrit.libreoffice.org/c/core/+/158513> "Directly use std::cmp_*, drop o3tl::cmp_*" cannot go in, yet Change-Id: If8b3ef1e647b6e33c43d0fe5737daf63eda0b761 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158524 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-25Use std::signed_integral conceptStephan Bergmann
...which, unlike std::is_signed, also requires that T is an integer type, not just any arithmetic type, but which appears to fit well here anyway. But LLVM 12 libc++, which is apparently used by Android builds, only provides a bare-bones <concepts> that lacks std::signed_integral (among others), so for now introduce o3tl/concepts.hxx providing what's missing (incl. std::integral and std::unsigned_integral, for some kind of consistency). Change-Id: I1c37d37fa1b57b5e3bf24c9e44f3973003905cb2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158406 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-12Fix typos in C++ feature test macrosStephan Bergmann
...that were accidentally made in e6fe048ded34a322007547d4d31e32c598aa4993 "Some more string_view use, add o3tl::starts/ends_with" Change-Id: I06470f705d1f51f98daffabe544c0194dfc34ee3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157832 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-11Drop o3tl::span, can use C++20 std::span directly nowStephan Bergmann
Change-Id: Ic21ff7bf48f07f7277979d52e99d2c5c268de83f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157825 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-09-26tdf#146619 Recheck include/o3tl with IWYUGabor Kelemen
Change-Id: I25833a776b4b7f2055805159583f363b860bc4cf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156987 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2023-05-06update loplugin:stringview* for o3tl::iterateCodePointsNoel Grandin
And change o3tl::iterateCodePoints to use sal_Int32 for its second param, to integrate better with places where the parameter comes from an UNO API, which cannot use std::size_t Change-Id: I7b9dd2c9bc7f48e6c4a912f039f1b5dae7beae69 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151421 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-05-05Break comphelper::adjustIndexToStartOfSurrogate out of o3tl::iterateCodePointsStephan Bergmann
...as what they do is orthogonal (and it turned out that the use case that motivated the addition of o3tl::iterateCodePoints in the first place needs them independently, anyway) Change-Id: Id33901a2f7ac627253654ee6d883305dcf5a456f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151415 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-05-05Fix typo in assertStephan Bergmann
I accidentally broke this in fa0c012d6c06e9a92093dacf997fe3151272648e "Provide std::u16string_view based o3tl::iterateCodePoints" when moving the body of code from rtl_uString_iterateCodePoints to here and then adapting it from sal_Int32- base OUString to std::size_t-based std::u16string_view. Change-Id: I5bd97413ac8c8482f409ad5be3797fef47191d33 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151409 Tested-by: Stephan Bergmann <sbergman@redhat.com> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-05-05Fix typoAndrea Gelmini
Change-Id: If680acecd66a59f2fcd12aa8121bdf548404ca51 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151405 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-05-04Provide std::u16string_view based o3tl::iterateCodePointsStephan Bergmann
...as requested in the comments of <https://gerrit.libreoffice.org/c/core/+/151303> "a11y: Fix returning unpaired surrogates when retrieving characters" (incl. the additional preAdjustIndex parameter). The type of the indexUtf16 parameter obviously needed to be adapted to std::u16string_view's std::size_t. But there is no obvious best choice for the type of the incrementCodePoints parameter (int? std::ssize_t?), so lets leave it as sal_Int32. For simplicity of avoiding a Library_o3tl, and to allow o3tl::iterateCodePoints to be used in the implementation of rtl_uString_iterateCodePoints now, o3tl::iterateCodePoints is provided as an inline function defined in the include file. Change-Id: I8280ca11d2a943bd2b7150a266807b358f321a72 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151366 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-04-22Introduce o3tl::toU converting wstring_view to u16string_viewMike Kaganski
Change-Id: I5be9aa767020c2516984e47fcd0f51d4661fdf17 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150779 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-04-22clang-format char16_t2wchar_t.hxxMike Kaganski
Change-Id: I5b86fb372702e3a6fdb3e4aa6846c4bc2e754307 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150778 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-04-14Another micro-optimizationMike Kaganski
I was surprised to see that all three major compilers generate better code using the pointer arithmetics compared to indices. Change-Id: I934a840a43159babf51f337b4af7f972424ff4fb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150323 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-04-14loplugin:stringviewparam improvementsNoel Grandin
improve the check by checking for methods that exclude using string_view, rather than checking for methods that __can__ use string_view, which leads to exposing some holes in our o3tl/string_view.hxx coverage. Change-Id: Ic9dd60441c671f502692f9cd2a1bb67301c4b960 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150277 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-04-13deduplicate o3tl::trimMike Kaganski
Change-Id: I5d4b3555b59b5abf622c389662e83cbd0f7d142d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150213 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-04-12Use o3tl::trim in strtmpl.hxxMike Kaganski
Change-Id: I4de8658c36c21fe07fa45f697cf3145c567a95c0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150210 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-04-12fix o3tl::equalsAsciiLNoel Grandin
after I got it wrong in both the original commit commit d15a6560bd445cd1931e9fded6ad8ecfdd54211b use more string_view and in the attempted fix commit dd41ea3ec1f579fabb9f674184b52c1be77e2fdb fix for o3tl::equalsAscii thanks to sberg for spotting that Change-Id: Iff12879de823553b2623db48979e9a720302f2d7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150240 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-04-11use more string_view in o3tl::equalsAsciiNoel Grandin
Change-Id: I1445a179e0007152b96436da4520c30a6fe6575c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150218 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-04-11fix for o3tl::equalsAsciiNoel Grandin
from commit d15a6560bd445cd1931e9fded6ad8ecfdd54211b use more string_view where the new method was named incorrectly Change-Id: Ia4513fa67f5bda8b6cb56e3db22df48b5e3c7283 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150217 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-11-08Combine o3tl::RestoreGuard into comphelper::ValueRestorationGuardStephan Bergmann
Change-Id: Iec42b3bf348ba82a98d4ad8236a9e8b95fdfe5f1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142422 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-11-08Introduce o3tl::RestoreGuardStephan Bergmann
Change-Id: Ic0c1a73668e990c91ef6e90e8c01e669761fe356 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142403 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-11-07Fix typosAndrea Gelmini
Change-Id: Ie5df0153446e6af1c717c74dba722ac2aea2b738 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142379 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2022-11-05Introduce o3tl::sprintfStephan Bergmann
...in preparation for follow-up commits that will replace many uses of std::sprintf (which started to emit deprecation warnings with macOS 13 SDK now) across the code base with various alternatives Change-Id: I9602f1cb0e28d1b70c2356edb52d78dd165f1118 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142317 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-10-24Fix MulDivSaturate to avoid overflowMike Kaganski
Thanks to Caolan https://gerrit.libreoffice.org/c/core/+/110839/comments/5c47cab2_b0523546 > oss-fuzz has come up with a case of n 9223372036854775807 m 72 d 127 > > include/o3tl/unit_conversion.hxx:105:28: runtime error: signed integer > overflow: 9223372036854775807 + 63 cannot be represented in type 'long' Change-Id: I0fe26f6c854a90cf577a60528d15f3da5471b914 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141711 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-09-01cid#1500502,cid#1500623,cid#1500659 Resource leakNoel Grandin
Change-Id: I7025dd3616ab2404a688d50bb25f07d012b52ccb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139092 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-07-27o3tl: use std::array as the container for enumarrayTomaž Vajngerl
Change-Id: I482140a14a4f18014d89ed5b8ce7c3ca9447b8d6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137465 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-06-20Suppress unhelpful cid#1506515Stephan Bergmann
Change-Id: I8d1025a680ea5e4a6ec872478db118837dd91af4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136137 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-06-18o3tl: ensure that the initializer of enumarray contains enough elementsMichael Stahl
Currently this silently succeeds. Turns out oox already contains some too-short initializers, let's guess the missing properties are all invalid. One downside of the templated parameter pack approach in the enumarray ctor, as witnessed in vcl/win/window/salframe.cxx, is that argument types can no longer be implicitly deduced and thus need to be spelled explicitly now in certain cases. There were also three uses of enumarry with V being unsigned short (aka sal_uInt16) that started to cause narrowing conversion errors now and needed to be adapted: In editeng/source/uno/unonrule.cxx the obvious fix was to use the proper type for V. In sw/source/core/unocore/unosett.cxx with its odd mix of saL_Int16 and USHRT_MAX, lets keep things that way for now (probably awaiting later clean up) and use casts to avoid the implicit narrowing. And in sw/source/filter/ww8/wrtw8esh.cxx the ESCHER_Prop_* values, while presumably conceptionally of type sal_uInt16, are plain #defines (thus of type int), so rather than changing V to int it looked more consistent to explicitly cast the ESCHER_Prop_* vlaues to sal_uInt16. (And in tools/source/fsys/urlobj.cxx the poor loplugin:redundantfcast started to unhelpfully kick in for (only) the first argument now.) Change-Id: If06c29e673ec7e565e283c6f447889cf1f777cb7 Co-authored-by: Stephan Bergmann <sbergman@redhat.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135970 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-06-05cid#1504664 silence Operands don't affect resultCaolán McNamara
Change-Id: I9ec3ae0e8cb87ab8a98746b8e49fd3f969ea0bd9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135437 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-06-02Use more appropriate return type for ThreadPool::getPreferredConcurrencyStephan Bergmann
All call sites already effectively asked for an unsigned return type, including: * The ThreadPool ctor took an nWorkers argument of type sal_Int32, but internally stores that as std::size_t mnMaxWorkers. * ZipOutputStream::reduceScheduledThreadTasksToGivenNumberOrLess apparently benefits from an unsigned nThreadTasks parameter, getting rid of various casts in its implementation that were necessary to silence signed vs. unsigned comparison warnings. The only drawback is that comphelper::ThreadPool::getPreferredConcurrency() * 4 in package/source/zippackage/ZipPackageStream.cxx would now silently wrap around instead of causing UB on overflow (which could be detected with appropriate tools). Ideally, it would use some o3tl::saturating_mul if we had that, so add a TODO comment for now. While std::thread::hardware_concurrency returns unsigned, it looked more natural to go with std::size_t here, as some call sites already used that (see above), so the implementation of ThreadPool::getPreferredConcurrency is a natural place to hide clamping std::thread::hardware_concurrency() to std::size_t (in the unlikely case that std::size_t is of smaller rank than unsigned). This required addition of o3tl::clamp_to_unsigned in o3tl/safeint.hxx. Change-Id: I0a04a8b32e63ebfeb39f924c4b38520455a6fb38 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135309 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-06-02Suppress false positive cid#1504594Stephan Bergmann
Change-Id: I9a4a20a2725a050b7e3d0aa38cb4568e7462926c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135287 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-06-01Fix commentStephan Bergmann
For one, the functions are already available in C++20. For another, our fallback implementation is only an approximation, as it doesn't enforce the requirement that the involved template types "are standard integer types or extended integer types" (but which is at least checked in --with-latest-c++ builds against standard libraries that already provide those C++20 functions). Change-Id: I91208c185f2db681cf25899d3cd9a9e2912d32a0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135232 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-05-29New o3tl::intcmp.hxxStephan Bergmann
...introducing o3tl::cmp_equal etc. implementing C++23 std::cmp_equal etc., plus an o3tl::IntCmp wrapper around it for convenient operator syntax Change-Id: I1d2e0d1aef99c531039fb83de31ed8e6036fde03 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135095 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-05-19fix location of #includeNoel Grandin
after commit 343eed477ee7b55aa450bbc2aee6786dc0d9a071 clang-tidy modernize-pass-by-value in o3tl Change-Id: I1800c0ba63abb0862b8c9aef185ebdf416245f3e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134602 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
generated by cgit (git 2.34.1) at 2025-01-09 05:35:33 +0000