summaryrefslogtreecommitdiff
path: root/sal/qa/rtl
AgeCommit message (Collapse)Author
2023-11-29Extended loplugin:ostr: salStephan Bergmann
Change-Id: Ieca8096e2af9615fa4c34557a47bc13ee5c23936 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160105 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2023-11-19Extended loplugin:ostr: salStephan Bergmann
Change-Id: Ic8a02784acb9f8981249689541bb6cba1b7fbfb7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159682 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-11-08loplugin:stringstatic, lopluign:ostr (clang-cl)Stephan Bergmann
Change-Id: I7a928a2385286f6d1ab3887c8d315af3f47c052d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159135 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-11-03Make ExternalReferenceUriTranslator more robust against broken UTF-8Stephan Bergmann
<https://lists.freedesktop.org/archives/libreoffice/2023-November/091151.html> "CppunitTest_stoc_uriproc failed on Windows" reports that translateToExternal("file:///abc/%feef") produces an empty string (indicating failure) instead of "file:///abc/%FEef" (as expected in stoc/test/uriproc/test_uriproc.cxx) when osl_getThreadTextEncoding() is Shift JIS. This was due to how the call to rtl::Uri::encode in Translator::translateToExternal (in stoc/source/uriproc/ExternalUriReferenceTranslator.cxx) behaved: It internally interpreted its input "%FE" as the single-byte Shift JIS character 0xFE. Which gets mapped to U+2122 as an extension (see "APPLE additions over SJIS, we convert this like Apple, because I think, this gives better result, then [sic] we take a replacement char" in sal/textenc/tcvtjp6.tab) in readUcs4, but which in turn doesn't get mapped back to any Shift JIS character in writeEscapeChar. Translator::translateToExternal is the only user of rtl_UriEncodeStrictKeepEscapes, as introduced by 6ff5d3341dbc5df3f0cb5368ccb0e1089338916c "INTEGRATION: CWS c07v013_SRC680 (1.4.40); FILE MERGED: 2007/06/21 13:00:56 sb 1.4.40.1: #b6550116# Made XExternalUriReferenceTranslator.translateToExternal more robust when the input URL contains spurious non--UTF-8 octets like %FE (which are now copied verbatim, instead of signalling error)." To make the claim true that such "spurious non--UTF-8 octets like %FE" are always "copied verbatim", regardless of text encoding being used, repurpose rtl_UriEncodeStrictKeepEscapes to always treat any escape sequences that are present as (potentially broken) UTF-8. Change-Id: I0fa0b14d3e3d44e4b5514e1b73c84c407a947ce9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158888 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-20Extended loplugin:ostr: Automatic rewrite O[U]StringLiteral: salStephan Bergmann
Change-Id: If4a7951fd3f9f7f2e081e6b8ba482566260c3235 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158209 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-15Repurpose loplugin:stringstatic for O[U]String vars that can be constexprStephan Bergmann
...now that warning about O[U]String vars that could be O[U]StringLiteral is no longer useful Change-Id: I389e72038171f28482049b41f6224257dd11f452 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157992 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-11The other OStringLiteral ctor should be non-explicit tooStephan Bergmann
It had been missed by 31cd6fd0f3c856a81a03d0229de1c4d10442844f "Make OStringLiteral ctor non-explicit", and now prevented u8"..."_ostr from compiling. Change-Id: Ifb214fba0957b0d26b11daae6190ffa9d21713f0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157823 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-11Delete OUString UTF-16 string literal ctor/assignment opStephan Bergmann
...that have been made unused by 7ef3d937415185ef66e32dd3043783eddcd03db5 "loplugin:ostr: Rewrite some uses of O[U]String to use ""_ostr/u""_ustr literals". (And which means we can remove the relevant code from that plugin again.) (This also found a handful of remaining uses that had been hard for the plugin to discover, along the lines of > std::map<OUString, int> m = {{u"foo", 0}}; being represented by a > DeclStmt 0xdaca578 <line:103:5, col:50> > `-VarDecl 0xdac9150 <col:5, col:49> col:29 s11 'std::map<OUString, int>':'std::map<rtl::OUString, int>' cinit destroyed > `-ExprWithCleanups 0xdaca548 <col:35, col:49> 'std::map<OUString, int>':'std::map<rtl::OUString, int>' > `-CXXConstructExpr 0xdaca508 <col:35, col:49> 'std::map<OUString, int>':'std::map<rtl::OUString, int>' 'void (initializer_list<value_type>, const std::less<rtl::OUString> &, const allocator_type &)' list std::initializer_list > |-CXXStdInitializerListExpr 0xdaca480 <col:35, col:49> 'initializer_list<value_type>':'std::initializer_list<std::pair<const rtl::OUString, int>>' > | `-MaterializeTemporaryExpr 0xdaca468 <col:35, col:49> 'const std::pair<const rtl::OUString, int>[1]' xvalue > | `-CXXBindTemporaryExpr 0xdaca448 <col:35, col:49> 'const std::pair<const rtl::OUString, int>[1]' (CXXTemporary 0xdaca448) > | `-InitListExpr 0xdac9df0 <col:35, col:49> 'const std::pair<const rtl::OUString, int>[1]' > | `-CXXConstructExpr 0xdaca408 <col:36, col:48> 'const std::pair<const rtl::OUString, int>' 'void (const char16_t (&)[4], int &&) noexcept(_S_nothrow_constructible<const char16_t (&)[4], int>())' list > | |-StringLiteral 0xdac91b8 <col:38> 'const char16_t[4]' lvalue u"foo" > | `-MaterializeTemporaryExpr 0xdaca3f0 <col:46> 'int' xvalue > | `-IntegerLiteral 0xdac91d8 <col:46> 'int' 0 > |-CXXDefaultArgExpr 0xdaca498 <<invalid sloc>> 'const std::less<rtl::OUString>':'const std::less<rtl::OUString>' lvalue > `-CXXDefaultArgExpr 0xdaca4b8 <<invalid sloc>> 'const allocator_type':'const std::allocator<std::pair<const rtl::OUString, int>>' lvalue Clang AST.) Change-Id: I496fe9d4d5e1a033cb7b27b4e04b303f8ddbed4a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157756 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-10-07loplugin:ostr: automatic rewriteStephan Bergmann
Change-Id: I2d09b2b83e1b50493ec88d0b2c323a83c0c86395 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157647 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins
2023-09-29Drop some newly obsolete __cplusplus version checksStephan Bergmann
...after 1eef07805021b7ca26a1a8894809b6d995747ba1 "Bump baseline to C++20". Which revealed that at least for VS 2019 16.11.30 (but not for at least VS 2022 17.7.4), in /clr mode (e.g., when compiling cli_ure/source/climaker/climaker_app.cxx), the -std:c++20 is effectively ignored, and compilation of such source files failed with > include\rtl/string.hxx(191): error C2955: 'rtl::OStringLiteral': use of class template requires template argument list > include\rtl/string.hxx(88): note: see declaration of 'rtl::OStringLiteral' > include\rtl/string.hxx(191): error C7592: a non-type template-parameter of type 'rtl::OStringLiteral' requires at least '/std:c++20' > include\rtl/string.hxx(397): error C2955: 'rtl::OStringLiteral': use of class template requires template argument list > include\rtl/string.hxx(88): note: see declaration of 'rtl::OStringLiteral' etc. To work around that, keep the 27d1f3ac016d77d3c907cebedca558308f366855 "O[U]String literals (unusable for now, C++20 only)" functionality disabled when compiling /clr sources (i.e., where _MANAGED is defined) for that old compiler. Change-Id: If62ceef5f8e55a828b880f197111fe387e4953fe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157205 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-09-24Drop some newly obsolete __clang_major__ version checksStephan Bergmann
...after 6ef2d358ac053ce0f6de9cf0f8f25e8bae66d441 "Adapt Clang and GCC minimum version checks" Change-Id: Ib25fbb76211d1bda1d230de771f207960e645421 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157204 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-09-24Drop some newly obsolete __GNUC__ version checksStephan Bergmann
...after 6ef2d358ac053ce0f6de9cf0f8f25e8bae66d441 "Adapt Clang and GCC minimum version checks" Change-Id: I5f3bcda2ce8e0e093af3bdd9d2cca741a5b95306 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157202 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-08-22tdf#146619 Remove unused includes from sal/qaGabor Kelemen
also drop now-unused osl_Condition_Const.h Change-Id: I40beb5b1ad49c126a126bb444d5f66703664d56d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155820 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-08-04Avoid a Clang template instantiation bug with libstdc++ and C++20Stephan Bergmann
See patch set 2 of <https://gerrit.libreoffice.org/c/core/+/155121/2> "Bump baseline to C++20" for how that would affect us here, > /opt/rh/gcc-toolset-12/root/usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/basic_string.h:620: error: undefined reference to 'void std::__cxx11::basic_string<char16_t, std::char_traits<char16_t>, std::allocator<char16_t> >::_M_construct<char16_t const*>(char16_t const*, char16_t const*, std::forward_iterator_tag)' > clang-12: error: linker command failed with exit code 1 (use -v to see invocation) > make[1]: *** [/home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/solenv/gbuild/LinkTarget.mk:841: /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/workdir/LinkTarget/CppunitTest/libtest_sal_rtl.so] Error 1 (<https://ci.libreoffice.org/job/gerrit_linux_clang_dbgutil/145874/>) Change-Id: Ibda1a5687a16e45aa0e77958f2bf547766cb0f48 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155343 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-07-31loplugin:stringconstant: Catch some O[U]String::getStr anti-patternsStephan Bergmann
Change-Id: I36bc86fcffc3c10fe44e60d779c9aa48eeed00f2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154749 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-07-31Fix C++20-only "..."_tstr test codeStephan Bergmann
...added by 6fce450b8a66d7e98a4d39528f8591184277e9fa "Introduce "..."_tstr as a companion to "..."_ostr/u"..."_ustr in template code" Change-Id: I779cf8e586b2a57aadfe9e57a546ee613bb505e3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155093 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-07-31Introduce "..."_tstr as a companion to "..."_ostr/u"..."_ustr in template codeStephan Bergmann
...like > *path = "/"; in > template<typename T> oslFileError getSystemPathFromFileUrl( > OUString const & url, T * path, bool resolveHome) in sal/osl/unx/file_url.cxx, where T is either OString or OUString. That can now be replaced with > *path = "/"_tstr; and for OString it will be a no-cost constexpr operation, while for OUString it will still construct the OUString instance at runtime (as did the original code for both OString and OUString). (This change required moving the definition of rtl::detail::OStringHolder around in include/rtl/string.hxx. For consistency, I similarly moved around the definition of rtl::detail::OUStringHolder in include/rtl/ustring.hxx, too.) Change-Id: I7fb3a81b438f98c609684f7e70b7a60068d32fdb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154748 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-07-19Work around MSVC bug with "..."_ostr vs. u"..."_ostrStephan Bergmann
Since 27d1f3ac016d77d3c907cebedca558308f366855 "O[U]String literals (unusable for now, C++20 only)", <https://developercommunity.visualstudio.com/t/Using-same-string-literal-suffix-for-cha/10416970> "Using same string literal suffix for char and char16_t string overloads causes 'no matching overloaded function found'" caused --with-latest-c++ builds to fail with > sal/qa/rtl/strings/test_oustring_stringliterals.cxx(432): error C2672: '""_ostr': no matching overloaded function found > include\rtl/ustring.hxx(3604): note: could be 'rtlunittest::OUString operator ""_ostr(void)' > include\rtl/string.hxx(2402): note: or 'rtlunittest::OString operator ""_ostr(void)' > sal/qa/rtl/strings/test_oustring_stringliterals.cxx(432): error C2672: 'CppUnit::assertEquals': no matching overloaded function found > workdir\UnpackedTarball\cppunit\include\cppunit/TestAssert.h(161): note: could be 'void CppUnit::assertEquals(const T &,const T &,CppUnit::SourceLine,const std::string &)' > sal/qa/rtl/strings/test_oustring_stringliterals.cxx(432): note: 'void CppUnit::assertEquals(const T &,const T &,CppUnit::SourceLine,const std::string &)': expects 4 arguments - 3 provided etc. So help MSVC along by renaming from u"..."_ostr to u"..."_ustr for now. Change-Id: Iad401f0681ac9326b7c57259c5483263ddfbfd4e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154634 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-07-14O[U]String literals (unusable for now, C++20 only)Stephan Bergmann
Change-Id: I0ecd1a8b60a01aefdf0139e3777dc006532764fd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154434 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-06-26new loplugin:constexprliteralNoel Grandin
OUStringLiteral should be declared constexpr, to enforce that it is initialised at compile-time and not runtime. This seems to make a different at least on Visual Studio Change-Id: I1698f5fa22ddb480347c2f4d444530c2e0e88d92 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153499 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2023-06-02tdf#145538,tdf#147021: qa: range based loopsDr. David Alan Gilbert
A bunch of range based loop changes in various qa sections that also take out about 1% of SAL_N_ELEMENTS Change-Id: I8ef000e9aa400cd8363b48f6175f6ab258cefbd9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152422 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-05-07Revert a thinko from commit 876010cbc4584249e919c694b8b977fd4e83084eMike Kaganski
Indeed, the cDecSeparator and cGroupSeparator require that the buffer uses the proper character type, otherwise it won't be possible to use Unicode separators in rtl_math_doubleToUString. Change-Id: Id26bed72776475c1be5b092e3ffcff0e75ffe557 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151451 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-04-10Use of O(U)StringNumber for float/double is actually a pessimisationMike Kaganski
They use rtl_(u)str_valueOf(Float|Double), to fill the buffer, and the latter use doubleToString, which creates an rtl_(u)String, copies to the buffer, and releases the rtl_(u)String. So instead just use the rtl_(u)String from rtl_math_doubleTo(U)String directly. Even when the end result is not needed as O(U)String, this would avoid an extra copy step. Also, this avoids separate LIBO_INTERNAL_ONLY implementations. Change-Id: Ib1d9ecebd7876dfff7dc758f89ee4c1536647a50 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150150 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-04-05Simplify O(U)String::number implementationMike Kaganski
Change-Id: I059f0324597a90aee01c95170a48ac5578f3caee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150037 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-04-04Make O(U)String::boolean also return an O(U)StringNumberMike Kaganski
Change-Id: I184fa0e4e45662e0fac86076d1c8733a0465bb56 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149978 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-03-15Related: tdf#152943 Test that a quiet NaN payload is propagatedEike Rathke
Change-Id: Ib98b507db9305ed20e3000f7f457a135a3bb3836 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148936 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2023-02-16Only specialize CppUnit::assetion_traits<T>::toString member functionsStephan Bergmann
...not the whole CppUnit::assetion_traits<T> classes (where applicable). That avoids spelling out the (identical) equals member functions, and also leaves around the less and lessEqual member functions, in case they want to be used after all. Change-Id: I18f8d6cff0353921ced4952b33a0c85ff8292923 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147165 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-11-08A better fix for C++23 P2266R1Stephan Bergmann
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 Bergmann
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 Kaganski
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 Nabet
...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 Hao
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 Hao
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 Bergmann
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 Grandin
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 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-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-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>
generated by cgit (git 2.34.1) at 2025-02-24 16:46:40 +0000