summaryrefslogtreecommitdiff
path: root/sal/qa
AgeCommit message (Collapse)Author
2022-03-31A string_view is not necessarily NUL-terminatedStephan Bergmann
Regression introduced into LIBO_INTERNAL_ONLY code with 1da69081732c8a429840edaaf10cfb789ea68df8 "add string_view variants of methods to O[U]StringBuffer". And add some tests. Assigning an OStringChar to an OStringBuffer also uses the std::string_view assignment operator, so also test that with testOStringChar, even though there it is relatively likely that the OStringChar temporary is followed by null bytes, which could make the test happen to erroneously succeed. But at least tools like ASan or Valgrind could catch that. On the other hand, assigning an OUStringChar to an OUStringBuffer does not use the std::u16string_view assignment operator (and rather uses a ConstCharArrayDetector-based one, which was similarly broken and has been fixed in b66387574ef9c83cbfff622468496b6f0ac4d571 "Fix -Werror=array-bounds"), so there's no test for that here. Change-Id: I7cf10ee5ce0e4280a91d116cd82d4871a0f44af6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132363 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-03-31Fix -Werror=array-boundsStephan Bergmann
> In file included from svtools/source/svrtf/parrtf.cxx:28: > In member function ‘typename rtl::libreoffice_internal::ConstCharArrayDetector<T, rtl::OUStringBuffer&>::TypeUtf16 rtl::OUStringBuffer::operator=(T&) [with T = const rtl::OUStringChar_]’, > inlined from ‘virtual int SvRTFParser::GetNextToken_()’ at svtools/source/svrtf/parrtf.cxx:183:94: > include/rtl/ustrbuf.hxx:352:20: error: array subscript ‘unsigned int[0]’ is partly outside array bounds of ‘rtl::OUStringChar [1]’ {aka ‘const rtl::OUStringChar_ [1]’} [-Werror=array-bounds] > 352 | std::memcpy( > | ~~~~~~~~~~~^ > 353 | pData->buffer, > | ~~~~~~~~~~~~~~ > 354 | libreoffice_internal::ConstCharArrayDetector<T>::toPointer(literal), > | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 355 | (n + 1) * sizeof (sal_Unicode)); //TODO: check for overflow > | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > svtools/source/svrtf/parrtf.cxx: In member function ‘virtual int SvRTFParser::GetNextToken_()’: > svtools/source/svrtf/parrtf.cxx:183:94: note: object ‘<anonymous>’ of size 2 > 183 | aToken = OUStringChar( static_cast<sal_Unicode>(nTokenValue) ); > | ^ as seen with recent GCC 12 trunk in an --enable-optimized build. And add a test, even though it is relatively likely that the OUStringChar temporary is followed by null bytes, which would make the test happen to erroneously succeed. But at least tools like ASan or Valgrind could catch that. (For the corresponding OStringChar and OStringBuffer scenario, this issue does not arise, as OStringChar is not covered by ConstCharArrayDetector, so the correpsonding OStringBuffer assignment operator is OK memcpy'ing n+1 elements. There /are/ similar issues with string_view assignment operators for both O[U]StringBuffer, which will be addressed in a later commit.) Change-Id: Ia131d763aa5f8df45b9625f296408cc935df96ac Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132354 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-03-29Add back the opportunity to leave O[U]StringLiteral's buffer uninitializedStephan Bergmann
...once we have a C++20 baseline, which would render uses of the consteval O[U]StringLiteral ctors ill-formed if we accidentally failed to write to all of buffer's elements. This had been broken (and the TODO comments had become misleading) with 21584b304b21bfe6b99b6f29018c6b754ea28fc0 "make OUString(OUStringLiteral) constructor constexpr" and bca539e889d40e06cb3275442622cb075b2484a2 "make OString(OStringLiteral) constructor constexpr". Also add corresponding test code. Change-Id: I2bc680282c717d403a681ff4b9396580c8382de1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132275 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-03-24-Werror,-WformatStephan Bergmann
Change-Id: Ifb282ae907495ab21f3a91b1cae1c34443cb3626 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132018 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-03-09Drop misguided test added in 82a1d32d3d3ac1b4b0a6d4cfaca791c77d9b3c03Mike Kaganski
The documented precondition is that index must not be greater than the length of string. Just assert that, and fix the found misuse. The added test is for in-place replacement, just in case. Change-Id: I3c545a6f0bf913fe93e2bef83ce733359c193065 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131232 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
2022-03-09Simplify getTokenMike Kaganski
It should not attempt to dereference pointers when nIndex is negative. Properly handle too large nIndex. Also it is not necessary to parse the string when nToken is negative. Related to commit be281db569bafaac379feb604c39e220f51b18c4 Author Rüdiger Timm <rt@openoffice.org> Date Mon Sep 20 07:43:20 2004 +0000 INTEGRATION: CWS ause011 (1.18.22); FILE MERGED 2004/08/18 11:47:54 sb 1.18.22.1: #i33153# Made getToken more robust. Change-Id: I6fc77a5b70308ccca08cb2132bd78d024bd7e3e0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131221 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-03-08Fix --with-latest-c++ buildStephan Bergmann
> In file included from workdir/UnpackedTarball/cppunit/include/cppunit/TestAssert.h:8, > from workdir/UnpackedTarball/cppunit/include/cppunit/TestCase.h:6, > from workdir/UnpackedTarball/cppunit/include/cppunit/TestCaller.h:5, > from workdir/UnpackedTarball/cppunit/include/cppunit/extensions/HelperMacros.h:9, > from sal/qa/rtl/oustring/rtl_ustr.cxx:25: > workdir/UnpackedTarball/cppunit/include/cppunit/tools/StringHelper.h: In instantiation of ‘typename std::enable_if<(! std::is_enum<_Tp>::value), std::__cxx11::basic_string<char> >::type CppUnit::StringHelper::toString(const T&) [with T = char16_t; typename std::enable_if<(! std::is_enum<_Tp>::value), std::__cxx11::basic_string<char> >::type = std::__cxx11::basic_string<char>]’: > workdir/UnpackedTarball/cppunit/include/cppunit/TestAssert.h:74:50: required from ‘static std::string CppUnit::assertion_traits<T>::toString(const T&) [with T = char16_t; std::string = std::__cxx11::basic_string<char>]’ > workdir/UnpackedTarball/cppunit/include/cppunit/TestAssert.h:168:58: required from ‘void CppUnit::assertEquals(const T&, const T&, SourceLine, const std::string&) [with T = char16_t; std::string = std::__cxx11::basic_string<char>]’ > sal/qa/rtl/oustring/rtl_ustr.cxx:696:17: required from here > workdir/UnpackedTarball/cppunit/include/cppunit/tools/StringHelper.h:25:9: error: use of deleted function ‘std::basic_ostream<char, _Traits>& std::operator<<(basic_ostream<char, _Traits>&, char16_t) [with _Traits = char_traits<char>]’ > 25 | ost << x; > | ~~~~^~~~ > In file included from include/rtl/ustring.hxx:34, > from sal/qa/rtl/oustring/rtl_ustr.cxx:22: > ~/gcc/trunk/inst/include/c++/12.0.1/ostream:558:5: note: declared here > 558 | operator<<(basic_ostream<char, _Traits>&, char16_t) = delete; > | ^~~~~~~~ Change-Id: I70ae970c10650d0e6efa5ced3a354090642d5387 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131164 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-03-07Add unit tests for searching empty substring / zero characterMike Kaganski
Related to commit 713c83c0fc4a0d9950cfa0b598d7c5f4bae15755 Add checks to avoid finding empty substring / zero character This activates tests in sal/qa/rtl/oustring/rtl_ustr.cxx Change-Id: Iab176e6583dc383a7a3413b0e19cc8f0d09b2824 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131087 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-03-04Avoid "ThreadSanitizer: unlock of an unlocked mutex"Stephan Bergmann
...in (somewhat contorted) test code Change-Id: I247a30e580b3d458eb748a833100a662c9890d99 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130991 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-03-04Drop commented out wrong testsMike Kaganski
Change-Id: Ief086996f94978d2ffd6879a6c3e5b0b2312dffe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130962 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-03-04Enable tests in rtl_str.cxxMike Kaganski
And disable the tests that try to use nullptr where it's not accepted. Change-Id: I1cd031e371485fdd57e7691565376253a01049c3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130938 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-02-25Make an -fsanitize=undefined workaround conditionalStephan Bergmann
...that had been introduced with b5cb4935c268f12e63b61e035b455b0a59e67aa2 "Work around undef conversion of large double to float" but should no longer be necessary with <https://github.com/llvm/llvm-project/commit/9e52c43090f8cd980167bbd2719878ae36bcf6b5> "Treat the range of representable values of floating-point types as [-inf, +inf] not as [-max, +max]" added towards Clang 9. Thanks to Mike Kaganski for pointing me at this old code and at Richard Smith's comment at <https://cplusplusmusings.wordpress.com/2013/03/26/testing-libc-with-fsanitizeundefined/>. Change-Id: I8ecf115fcf6b1ebf621cb4567f8d31ac9b10ef1c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130531 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-02-17Use Dragonbox to implement doubleTo*String*Mike Kaganski
This header-only library is accurate in decimal representation of doubles; provides API that allows to create custom representation - so it's possible to use custom decimal separators and grouping. This allows to unify all corner cases: integers, numbers close to DBL_MAX, up-rounding to the next decade. Note that Dragonbox creates the shortest decimal representation of the number, that is unambiguously convertible back to the same number; thus it may hide trailing digits that are unneeded for such conversion. The functional changes are minimal, and beneficial: 1. Rounding numbers close to DBL_MAX now takes into account the bEraseTrailingDecZeros argument, as it should, allowing to have "1.8E+308" for rounding DBL_MAX to 2 decimals without trailing zeroes, instead of previous "1.80E+308". 2. Incorrect rounding is fixed in some cases, e.g. 9.9999999999999929 rounded to 10 previously using rtl_math_DecimalPlaces_Max. 3. Representing the number in the shortest way may change display of some printed numbers. E.g., 5th greatest double is represented as "1.797693134862315E+308" instead of a bit longer, but giving the same double on roundtrip, "1.7976931348623149E+308". This would generally look better for some numbers similar to the famous 0.1, where users would likely expect more "round" representation where it's unambiguous (but we still truncate to 15 significant decimals anyway - so there's no point in pretending to provide exact digits for actual binary representation). These are reflected in the unit tests affected by the change. Change-Id: I05e20274a30eec499593ee3e9ec070e1269232a2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129948 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-02-17Bump Linux Clang baseline to 8.0.1Stephan Bergmann
...as discussed in the mail sub-thread starting at <https://lists.freedesktop.org/archives/libreoffice/2022-February/088476.html> "Also bump Linux Clang baseline to 12.0.1 (was: Bump --enable-compiler-plugins Clang baseline?)", and clean up newly-obsolete __clang_major__ checks Change-Id: Idacb9148b019c07e138277df3a085ba71c64a8e1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130028 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-12-16Fix typosAndrea Gelmini
Change-Id: I66feced8bed05c7859e36a6d2f746a7faf30c7a4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126915 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Jenkins
2021-12-14Drop brittle testStephan Bergmann
Not only did it not work on Windows (witness the #ifdef), it would also fail at least for Linux Flatpak builds (if they did make checks) where creating <file:////tmpname> happens to succeed with E_None. Change-Id: I9b82d500cb37fb80648407d2b4ade5ac85e97a60 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126831 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-12-14A more expressive CPPUNIT_ASSERT_MESSAGEStephan Bergmann
Change-Id: I65d64002e5021c84af9ad7b8f5b693f04d79d4ec Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126797 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-11-11Drop the OUString vs. OUStringLiteral comparison operator overloadsStephan Bergmann
...which can be subsumed by their OUString vs. OUString counterparts now that conversion from OUStringLiteral to OUString is cheap since e6dfaf9f44f9939abc338c83b3024108431d0f69 "Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uString". (The only place that needed adaption was the dubious use of temporary OUStringLiteral instances in sal/qa/rtl/strings/test_oustring_stringliterals.cxx, which now caused "error: conversion function from 'rtlunittest::OUStringLiteral<6>' to 'const rtlunittest::OUString' invokes a deleted function".) Change-Id: I4f0f96efa2d5331ed5cbc9a29bdfdf3c0f4148a7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125020 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-10-22Optimize assignment from OUStringLiteral to OUStringStephan Bergmann
...by making the OUString's pData point to the OUStringLiteral, instead of copying the contained characters. This is one of the improvements that had not been done as part of e6dfaf9f44f9939abc338c83b3024108431d0f69 "Turn OUStringLiteral into a consteval'ed, static-refcound rtl_uString": "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." (Simply dropping the OUStringLiteral overload was not possible in this case, though, as that would have lead to ambiguities among the various OUString and std::u16string_view overloads.) The now-deleted OUStringLiteral rvalue reference overload means that some existing assignments from ternary-operator OUStringLiteral<N> to OUString no longer compile and had to be replaced with uses of std::u16string_view. Those had not already been replaced in e6dfaf9f44f9939abc338c83b3024108431d0f69 because they happened to use OUStringLiteral instances of identical length N in both arms of the ternary operator, so did not already start to fail to compile back then. Change-Id: I328e25b8324d045774e811d20a639f40d6a9a960 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124040 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-10-16Simplify vector initialization in salJulien Nabet
Change-Id: Ia3e4dd8cad79b156d44eb03f1ae3d308204df2e9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123691 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-10-03A more lightweight O[U]StringConcatenationStephan Bergmann
...compared to a full-blown O[U]String, for temporary objects holding an O[U]StringConcat result that can then be used as a std::[u16]string_view. It's instructive to see how some invocations of operator ==, operator !=, and O[U]StringBuffer::insert with an O[U]StringConcat argument required implicit materialization of an O[U]String temporary, and how that expensive operation has now been made explicit with the explicit O[U]StringConcatenation ctor. (The additional operator == and operator != overloads are necessary because the overloads taking two std::[u16]string_view parameters wouldn't even be found here with ADL. And the OUString-related ones would cause ambiguities in at least sal/qa/rtl/strings/test_oustring_stringliterals.cxx built with RTL_STRING_UNITTEST, so have simply been disabled for that special test-code case.) Change-Id: Id29799fa8da21a09ff9794cbc7cc9b366e6803b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122890 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-10-02Some corner case unit testsMike Kaganski
Change-Id: I43474265a9b3e1d07394c5f7e429e081d67f2eda Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122935 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-10-01Add unit test to catch eae24a9488814e77254d175c11fc4a138c1dbd30Mike Kaganski
Change-Id: I18b98f4be3212199004a1bb8fd8725fe71254ec4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122870 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-09-30Add a test for a negative integerMike Kaganski
Change-Id: I368123ce4ffdfb0e5c47e80cf4fece0c6ddc5f9d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122854 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-08-20New loplugin:unusedcapturedefaultStephan Bergmann
In sc/qa/unit/ucalc_formula.cxx, dropping the capture-default from the lExpectedinF lambda revealed that MSVC in C++17 mode (i.e., when building without --with-latest-c++) requires ROW_RANGE (a local const int variable from the enclosing TestFormula::testTdf97369) to be captured, even though all uses of that variable within the lambda body are constant expressions. That is still true at least for the latest Visual Studio 2019 version 16.11.1. (This is not an issue for the lExpectedinH and lExpectedinI lambdas a few lines further down, as they, in addition to using that ROW_RANGE, also use the local const double variables SHIFT1 and SHIFT2, whose uses are not constant expressions, so they are implicitly captured and loplugin:unusedcapturedefault does not suggest dropping those lambdas' capture-defaults in the first place.) Change-Id: Iee7efb485187cbe8eba6a2d470afca4993eb1816 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120693 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-08-18GCC bug 96878 is fixed in upcoming GCC 12Stephan Bergmann
However, restricting the workaround to GCC <= 11 then revealed that some old versions of Clang apparently had a similar issue, causing "error: use of class template 'OStringLiteral' requires template arguments; argument deduction not allowed here", and thus also need the workaround. I saw the non-workaround code fail with a build of Clang 6.0.0 and succeed with a build of Clang 7.0.0. Change-Id: I6e4cf6c8c3a11618a578401574e5679e6b65d7f4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120657 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-07-09Do not support +/-NaN with an explicit signStephan Bergmann
The code accepting "NaN" had been introduced with 92dafe9862d693ce9d79269627c3e6832422874e "dba33h: #i112652#: rtl/math.h: string<->double conversion and XMLSchema-2: [...] rtl_math_stringToDouble and rtl_math_uStringToDouble support XMLSchema-2 values in addition to deprecated previously supported values." The "XMLSchema-2" mentioned in that commit and in the corresponding <https://bz.apache.org/ooo/show_bug.cgi?id=112652> "ORB: report builder not handle correctly NULL values" presumably references <https://www.w3.org/TR/xmlschema-2/> "XML Schema Part 2: Datatypes Second Edition", where section "3.2.5 double" only supports "NaN" without a "+" or a "-" sign in the lexical representation. So stop accepting those. (I came across this in the context of 2b2b6405161025678f91a5625e50d0b414597368 "Reliably generate positive or negative NaN again", wondering whether this code should be updated too. But then decided that it is probably best not to allow that non-standard signed NaN notation for this case, and just keep producing for the "NaN" representation whatever std::numeric_limits<double>::quiet_NaN produces.) Change-Id: I035e78ca36240317f72f117d2b456fc474d8c08a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118647 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-07-08Reliably generate positive or negative NaN againStephan Bergmann
...after e5c80bb69a30dfb0a3daf6061ab127d92f8142d6 "Purge out setNan from math.cxx" had dropped the use of rtl::math::setNan and sign bit fiddling, and relied on the implicit assumption that std::numeric_limits<double>::quiet_NaN would produce a positive NaN (but which does not seem to be guaranteed by the C++ standard) and on the expressed hope that multiplying such a positive NaN by -1 would generate a negative NaN (but which does not seem to be guaranteed by IEEE 754: while it mandates that a NaN's payload is preserved across such an operation, the result's sign bit appears to be unspecified) Change-Id: I12215c888a1cb8de6b3f046a836c550cb21b5a85 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118604 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-06-28loplugin:indentation improve checks for brace alignmentNoel Grandin
Change-Id: I333100fda7e181f68f36b03279b3fbb8cb768310 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117615 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-06-02Revert "sb138: #i115619# fix for MinGW"Mike Kaganski
This reverts commit 6727dc5d9414e77975b9fd765993c6e207f872f3. We now don't support compiling using MinGW. Change-Id: I0dee00780bfb4b7deceddd8cd30af03b7f7ed212 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116591 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-06-01fix leak in SocketTestNoel Grandin
Change-Id: I8c5e2d4c4687beab08876fe3e945d19a1629bc36 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116514 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-05-31Replace inet_addr with inet_ptonStephan Bergmann
...as inet_addr is deprecated (it does not allow to distinguish successful return for "255.255.255.255" from -1 error return); and update tests Change-Id: I605cb2ba18fe9bd11d2d68c8f1c94271c4503509 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116441 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-05-31Replace inet_ntoa with inet_ntopStephan Bergmann
...as inet_ntoa is potentially not thread-safe; and add a test Change-Id: I9df945b006ba7194c3b1444c4886101c08339ad0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116425 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-05-14Improve loplugin:stringviewStephan Bergmann
Issue the "instead of O[U]String, pass [u16]string_view" diagnostic also for operator call arguments. (The "rather than copy, pass subView()" diagnostic is already part of handleSubExprThatCouldBeView, so no need to repeat it explicitly for operator call arguments.) (And many call sites don't even require an explicit [u16]string_view, esp. with the recent ad48b2b02f83eed41fb1eb8d16de7e804156fcf1 "Optimized OString operator += overloads". Just some test code in sal/qa/ that explicitly tests the O[U]String functionality had to be excluded.) Change-Id: I8d55ba5a7fa16a563f5ffe43d245125c88c793bc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115589 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-04-27loplugin:stringadd (clang-cl)Stephan Bergmann
Change-Id: Id7c2db4abcf947c4efa0296df29feca2c36d3cf8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114692 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-04-21loplugin:stringadd replace OUStringLiteral temporaries with OUString::ConcatNoel Grandin
Change-Id: I656f06a74d9f0180ae460264563d6a935c7d2c60 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114377 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-04-19use more string_view in OString APINoel Grandin
some parts of the OString seem to have fallen behind its more popular sibling OUString. Change-Id: Ie6d64c3005b2df5da49ba79d0c38282dd5057a23 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114252 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-03-25const OUString -> const OUStringLiteralMike Kaganski
Mostly automated rewrite Change-Id: Ie020a083f898bc126b8fb039d4ecb2e687172da1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112965 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-03-04Also check number of invocations in the testMike Kaganski
Change-Id: I4180f14aa633bf0f3f45178c1fd02b52b784f7e3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111960 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-03-04Improve unit test accuracyMike Kaganski
I didn't take clock resolution into account when created the test, and it failed for me occasionally because the value was slightly less than expected. The typical system tick resolution is documented at https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/high-resolution-timers Change-Id: Ie48b10d15b14f9ac7d292a2cc9916bcbfff44b6f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111946 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-03-03tdf#116983 tdf#136175: retry if failedMike Kaganski
Debugging the test case from the latter bug report shows that indeed the call to OleGetClipboard may fail first time, as jasonkres had suspected in the former bug. So follow the suggestion in tdf#116983, and retry the failing calls several times in case of failure. Many thanks to Telesto for preparing a clear bug report with reliable test case. Co-authored-by: jasonkres Change-Id: Ib3c497da830bc5faac586bcfe1eededa54bfa117 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111825 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-02-27Drop ComPtr and use sal::systools::COMReferenceMike Kaganski
Change-Id: I9eb6d99d883b44943ad69c2c28d4e55716dc34f9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111673 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-02-12Make sure to resolve symlinks in temp path in path testsMike Kaganski
This is a blind attempt to fix a part of a failure reported on IRC: /lode/dev/core/sal/qa/osl/file/osl_File.cxx:486: Assertion Test name: osl_FileBase::getAbsoluteFileURL::getAbsoluteFileURL_001_1 equality assertion failed - Expected: file:///var/folders/tj/jl7sh26124n4b94tm541m6xr0000gn/T//relative/file1 - Actual : file:///private/var/folders/tj/jl7sh26124n4b94tm541m6xr0000gn/T/relative/file1 - Assumption is wrong: ResultURL is not equal to expected URL That "private/" in Expected might be because user's /var is a symlink to /private/var. Change-Id: Ia5b95621dffdae7e0193aca4c3d12c86ed28dceb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110785 Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> Tested-by: Jenkins
2021-02-10Fix creation of some OUString from non-ASCII ordinary string literalsStephan Bergmann
On platforms where char is signed, > OUString aTmpName10(aTempDirectoryURL + "/\xE6\x9C\xAA\xE5\x91\xBD\xE5\x90\x8Dzhgb18030"); would have created, via addDataLiteral (include/rtl/stringconcat.hxx), an OUString containing sign-extended char16_t counterparts of the \x char values (\xE6 -> \uFFE6, etc.). That caused CppunitTest_sal_osl CPPUNIT_TEST_NAME=osl_FileBase::SystemPath_FileURL::getSystemPathFromFileURL_005 under an RTL_TEXTENCODING_ISO_8859_1 locale (e.g., LANG=C, as used by Fedora when executing the %check part of libreoffice.spec) to fail on such signed-char platforms (e.g., Linux x86_64) with > [_RUN_____] osl_FileBase::SystemPath_FileURL::getSystemPathFromFileURL_005 > createTestDirectory failed: 21! > sal/qa/osl/file/osl_File.cxx:267:osl_FileBase::SystemPath_FileURL::getSystemPathFromFileURL_005 > assertion failed > - Expression: (osl::FileBase::E_None == nError) || (nError == osl::FileBase::E_NOENT) > - In deleteTestDirectory function: remove Directory file:///tmp/?????????zhgb18030 -> result: 21 because FileURLToPath -> osl::detail::convertUrlToPathname -> getSystemPathFromFileUrl<rtl::OString> -> decodeFromUtf8 -> convert (all sal/osl/unx/file_url.cxx) would fail to convert those values beyond \u00FF to RTL_TEXTENCODING_ISO_8859_1, ultimately returning osl_File_E_INVAL (i.e., 21). (We could "fix" addDataLiteral in include/rtl/stringconcat.hxx, explicitly converting from char to char16_t via unsigned char, but arguably that concatenation construct should only be used with ASCII-only ordinary string literals, similar to the restrictions for OUString construction from such string literals.) (Before 5a77636c9a638c86fd3de3afb6e88cf48f987b6a "WIN enable osl_File.cxx part of CppUnitTest_sal_osl", that aTmpName10 was constructed as > OUString aTmpName10(RTL_CONSTASCII_USTRINGPARAM( FILE_PREFIX TEST_PLATFORM TEST_PLATFORM_TEMP "/\xE6\x9C\xAA\xE5\x91\xBD\xE5\x90\x8Dzhgb18030" )); but that would have caused similar issues, as RTL_CONSTASCII_USTRINGPARAM uses RTL_TEXTENCODING_ASCII_US which converts non-ASCII chars to RTL_TEXTENCODING_MS_1252 (see comment at aImplUSASCIIByteCvtData, sal/textenc/textenc.cxx), which would have converted e.g. \x9C to \u2018, which then would have failed to be converted to RTL_TEXTENCODING_ISO_8859_1. And that use of RTL_CONSTASCII_USTRINGPARAM had violated the requirements as stated in include/rtl/ustring.h anyway: "Each element of the referenced array must represent an ASCII value in the range 0x00--0x7F.") Whatever this crappy getSystemPathFromFileURL_005 actually wants to prove, it happens to work now also for RTL_TEXTENCODING_ISO_8859_1 locales. Change-Id: I044c4bd3aee4f7ea4f29737b6876cc55e4e6e436 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110714 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-02-10Be a bit more verbose in that crappy test codeStephan Bergmann
Change-Id: Ic0500db292d52a827f2139cd2cbbc0e8e4274dac Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110701 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-02-10Fix loplugin:stringliteralvarStephan Bergmann
...detection of OUString( const sal_Unicode * value, sal_Int32 length ) ctor. (On platforms where sal_Int32 is a typedef for int, an argument that already is of type int will not be wrapped in an ImplicitCastExpr to the sal_Int32 typedef.) Change-Id: Ifc5456a62d42c1acad76ea949549dc24bd67201a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110654 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-02-09loplugin:fakebool followed by loplugin:implicitboolconversion (clang-cl)Stephan Bergmann
Change-Id: I0f61268b2027eb617b2312615ea544387af1b381 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110643 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-02-09report what value was found in messageCaolán McNamara
Change-Id: I512cedcd46f829b97b62a57d90d5a4a81d024d66 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110562 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-02-08Improve loplugin:cppunitassertequal for CPPUNIT_ASSERT(a && b)Stephan Bergmann
...by re-enabling the code temporarily #if'ed-out in a528392e71bc70136021be4e3d83732fccbb885e "Fixed/improved loplugin:cppunitassertequals" (and which then triggers lots of other lopglugin:cppunitassertequal CPPUNIT_ASSERT -> CPPUNIT_ASSERT_EQUAL warnings). For two css::uno::Reference equality comparisons in cppu/qa/test_any.cxx, it was more straightforward to rewrite them with an explicit call to operator == (which silences loplugin:cppunitassertequal) than to adapt them to CPPUNIT_ASSERT_EQUAL's requirement for arguments of identical types. In sc/qa/unit/ucalc_pivottable.cxx, ScDPItemData needs toString, which has been implemented trivially for now, but might want to combine that with the DEBUG_PIVOT_TABLE-only ScDPItemData::Dump. Change-Id: Iae6d09cf69bd4e52fe4411bba9e50c48e696291c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110546 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-02-05Revert "Fix typo in code"Stephan Bergmann
This reverts commit 3ed9bba283a6a67864c0928186e277240be0d9ba. osl_Pos_Absolut (include/osl/file.h) is part of the stable URE interface; it must not be changed. Change-Id: I1f49923a9351e4be5aee39b10720d38b424feb9b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110435 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
generated by cgit (git 2.34.1) at 2024-12-26 22:18:12 +0000