summaryrefslogtreecommitdiff
path: root/sal/qa/rtl
AgeCommit message (Collapse)AuthorFilesLines
2022-11-08A better fix for C++23 P2266R1Stephan Bergmann1-0/+20
After 6d6a143913603b040c10a5db83c2103557899011 "Address some of the sprintf in vcl/source/fontsubset/cff.cxx", --with-latest-c++ builds that pick up a C++23 compiler that implements <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2266r1.html> "P2266R1: Simpler implicit move" started to fail with something like > vcl/source/fontsubset/cff.cxx:2061:16: error: no viable conversion from returned value of type 'char[64]' to function return type 'OString' > return aDefaultGlyphName; > ^~~~~~~~~~~~~~~~~ [...] > include/rtl/string.hxx:313:5: note: candidate constructor [with T = char[64]] not viable: expects an lvalue for 1st argument > OString( T& value, typename libreoffice_internal::NonConstCharArrayDetector< T, libreoffice_internal::Dummy >::Type = libreoffice_internal::Dummy() ) > ^ etc. So I figured there should be something better than 433ab39b2175bdadb4916373cd2dc8e1aabc08a5 "Adapt implicit OString return value construction to C++23 P2266R1" (which this commit reverts, modulo its conflicts in comphelper/source/xml/xmltools.cxx and sc/source/filter/xcl97/XclExpChangeTrack.cxx) to address the underlying issue in a way that keeps code that works up to C++20 also working in C++23. (The fix is only relevant for non-explicit constructors that involve NonConstCharArrayDetector and non-const lvalue references, not for other functions involving those. OUString has a similar constructor but which is explicit, and OUStringBuffer doesn't have any similar constructors at all, so this only affects OString and OStringBuffer constructors.) Change-Id: I31cf16b9507899f5999243f8467dfa24bc94c5ac Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142455 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-11-05-Werror,-Wdeprecated-declarations (sprintf, macOS 13 SDK): salStephan Bergmann1-0/+4
Change-Id: I668a8b4c6ce3458baa6975161be7ed0cb160968f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142331 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-10-11Deduplicate O(U)StringConcatenationMike Kaganski2-19/+19
And use an overloaded helper function with a better (?) unified name to show that the result is not an O(U)String. Change-Id: I8956338b05d02bf46a6185828130ea8ef145d46b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141203 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-09-15tdf#150877: Add support for Kamenický and Mazovia encodingsJulien Nabet1-1/+67
...as referenced e.g. at <https://docs.microsoft.com/en-us/previous-versions/visualstudio/foxpro/aa975345(v=vs.71)> "Code Pages Supported by Visual FoxPro". That source lists those two encodings with "code page" values 895 and 620, resp. (which might be what we call "Windows code pages" in include/rtl/tencinfo.h) and "code page identifier" values 0x68 and 0x69, reps. (which might be what we call "Windows charsets" in include/rtl/tencinfo.h. But I deliberately left these two new RTL_TEXTENCODING_* values without any mappings to such Windows codepages etc., as I didn't find any authoritative sources. What I used is the information available at <https://en.wikipedia.org/wiki/Kamenick%C3%BD_encoding> and <https://en.wikipedia.org/wiki/Mazovia_encoding>. (And while at it, I also updated the instructions what to do "Whenever some encoding is added here" in include/rtl/textenc.h.) This commit is building on some prior, abandoned work by Julien Nabet at <https://gerrit.libreoffice.org/c/core/+/139819> "tdf#150877: DBF Mazovia encoding (0x69)". Change-Id: Iae8af4ebab8915411499ae7ef951339b335aa857 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140014 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-08-23tdf#148430 Use std math functions instead of rtl::mathLiu Hao2-29/+224
Revert the changes in rtl unit tests. Add some new unit tests to demonstrate the behavior of std functions is same as rtl functions. Change-Id: I12603e2502b8d0951ff5e1650dc8fa193d67c856 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138696 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-08-19tdf#148430 Use std math functions instead of rtl::mathLiu Hao1-29/+29
Change-Id: I6bcb33d51c3974d0e8905e1ffeac556a99870aab Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138294 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@redhat.com>
2022-05-18Extend loplugin:redundantcast to trivial reinterpret_cast from T to itselfStephan Bergmann1-1/+1
Change-Id: I7c0be7b435d6b5f97bdd40484023584146638d70 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134506 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-04-27add string_view wrappers for rtl::math::stringToDoubleNoel Grandin1-35/+35
Change-Id: I114bec72cb933238675e539a8388a607226827cd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133455 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2022-03-31A string_view is not necessarily NUL-terminatedStephan Bergmann2-0/+64
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 Bergmann1-0/+5
> 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 Bergmann2-0/+35
...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 Bergmann1-1/+1
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 Kaganski2-12/+7
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 Kaganski1-0/+23
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 Bergmann1-0/+1
> 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 Kaganski2-429/+170
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-04Drop commented out wrong testsMike Kaganski1-95/+0
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 Kaganski1-223/+159
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 Bergmann1-1/+10
...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 Kaganski1-8/+5
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 Bergmann2-9/+6
...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-11-11Drop the OUString vs. OUStringLiteral comparison operator overloadsStephan Bergmann1-4/+6
...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 Bergmann1-1/+2
...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-03A more lightweight O[U]StringConcatenationStephan Bergmann2-19/+19
...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 Kaganski1-0/+12
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 Kaganski1-0/+5
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 Kaganski1-0/+6
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-18GCC bug 96878 is fixed in upcoming GCC 12Stephan Bergmann2-6/+21
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 Bergmann1-0/+14
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 Bergmann1-0/+16
...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-05-14Improve loplugin:stringviewStephan Bergmann1-1/+1
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-19use more string_view in OString APINoel Grandin1-2/+2
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 Kaganski1-4/+4
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-02-10Fix loplugin:stringliteralvarStephan Bergmann1-18/+14
...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-08Improve loplugin:cppunitassertequal for CPPUNIT_ASSERT(a && b)Stephan Bergmann4-11/+32
...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-01-28add string_view variants of methods to O[U]StringBufferNoel1-4/+4
and update the stringview loplugin to detect cases where we can use these new methods. Change-Id: I998efe02e35c8efcb3abfb4d7186165bbe6dfb2c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110046 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-01-27Improve loplugin:stringliteralvarStephan Bergmann1-6/+7
...to also consider O[U]String ctors taking pointer and length Change-Id: Iea5041634bfbf5054a1317701e30b56f72e940fb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110025 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-01-15OUString::matchAsciiL() can be used instead of the fresh startsWithAsciiL()Tor Lillqvist1-19/+0
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 Lillqvist1-0/+19
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 McNamara1-9/+9
Change-Id: I4884bfb67a061b865e8cf38b2fea6de0cb1bc3d6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109057 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-26New loplugin:stringliteralvarStephan Bergmann1-9/+9
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 Bergmann1-10/+10
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 Bergmann1-9/+9
...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-14Add empty OUStringBuffer::toString testStephan Bergmann1-0/+8
...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-08Improve a CPPUNIT_ASSERT messageStephan Bergmann1-1/+1
Change-Id: Ia40f249a115a8c4fe01fb384041b4542735166c0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107418 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-03tdf#138360: sal_rtl: Add unittestXisco Fauli1-0/+12
Change-Id: Iac6c4bf09f55446128d7fb7a35b483ca41bc4f00 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107080 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@redhat.com>
2020-11-28Unit tests for DBL_MAX to string conversion, tdf#136272Eike Rathke1-0/+88
Change-Id: Ied41d1e21fb6e40b54adac3c33fa0d096e25bada Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106783 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2020-11-21Relax non-null requirement for some rtl_uString_* functionsStephan Bergmann1-0/+118
...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 Hofer3-16/+16
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-11loplugin:stringviewNoel1-1/+1
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>
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-26 09:45:38 +0000