summaryrefslogtreecommitdiff
path: root/sal/qa
AgeCommit message (Collapse)AuthorFilesLines
2024-11-04new loplugin:staticconstexprNoel Grandin4-4/+5
Change-Id: Ida1996dfffa106bf95fd064e8191b8033b4002f3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175336 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-10-17extract NaN payload test from single unit testSakura2861-20/+3
Change-Id: I51a029c9ac729352fe435b9a70c5e8bd2cf746b1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174964 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2024-06-28Fix "lets" -> "let's"Andrea Gelmini1-1/+1
Change-Id: Ibe6cbbd618aab5c145913235dc90fec3c98cd504 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169723 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2024-05-15Unit test for tdf#160985Eike Rathke1-0/+14
Change-Id: I721d127b145b6524a946c42eb23f8004c700db11 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167648 Tested-by: Jenkins Reviewed-by: Eike Rathke <erack@redhat.com>
2024-04-28Extended loplugin:ostr manual changesStephan Bergmann1-1/+2
I had done these a while ago, when I looked into extending loplugin:ostr to do more automatic rewriting, and these were places where I needed to do something manually, for one reason or another, because the automatic rewriting would not pick it up correctly. However, I got distracted, and a wholesale automatic rewrite would still run into cases where an _ostr/_ustr instance from a library's .rodata would still be referenced after the library has already been dlcose'd. So I never came around to finishing all that. But there appears to be renewed interest in (automatic) rewritings here now, so it probably makes sense if I share this part of my work anyway. Change-Id: I3da9d38398e4bca373cb0000a9d34b49a36ad58a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166792 Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de> Tested-by: Jenkins
2024-04-26loplugin:ostr in salNoel Grandin24-423/+416
Change-Id: I7732a77fc5ac8d1f5c53052e0f4b6c7e7d70f054 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166739 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins
2024-02-27tdf#158190 Fix Calc ROUND in floating-point calculate result very close to X.5Po-Yen Huang1-0/+4
Location: if (nDecPlaces == 0) { switch (eMode) { case rtl_math_RoundingMode_Corrected: return std::round(fValue); Because the functions are the same as the following related codes, they are respectively: if (nDecPlaces >= 0 && (fValue >= 0x1p52 || isRepresentableInteger(fValue))) return fOrigValue; as well as: if (fValue < 0x1p52) { switch(eMode) { case rtl_math_RoundingMode_Corrected: fValue = rtl::math::approxFloor(fValue + 0.5); break; : : : Because some double-precision floating point numbers cause std::round(fValue) and rtl::math::approxFloor(fValue + 0.5) to produce different results. For example, enter 10614.4999999999876 in Calc's A1 cell (or any operation that will produce a long decimal number such as .499999999999xyz after the decimal point). We expected it to be 10614.4999999999876, but it was automatically rounded to 10614.5 (note: this result is also the result of ubiquitous handheld computers, OpenOffice.org and Excel) Then, entering =ROUND(A1,0) in B1, we will see 10614, A1 and B1 clearly don't meet expectations. (My boss or tax collector might be unhappy :-p) Although A1's 10614.4999999999876 is still faithfully recorded, the rendering of 10614.5 is confusing. Now, there are two views: 1. According to the established convention, B2 displays the expected answer 10615. or 2. True to the laws of mathematics, A1 displays 10614.4999999999876 or at least 10614.49 Although the second point of view is correct (and I completely agree with it), when opening spreadsheets generated by other software (such as OpenOffice.org or Excel), the results will be different, which people do not like to see. So when nDecPlaces == 0 is removed, use std::round(fValue) and let the existing code below it do the rounding: if (fValue < 0x1p52) { switch(eMode) { case rtl_math_RoundingMode_Corrected: fValue = rtl::math::approxFloor(fValue + 0.5); This is consistent with the first point. By the way, in nDecPlaces == 0 case rtl_math_RoundingMode_HalfEven: This piece of code can be checked to see if it is really necessary, because rtl_math_round() also has the same purpose code. If it is not needed, the entire nDecPlaces == 0 can be removed. Co-authored-by: Firefly <firefly@ossii.com.tw> Co-authored-by: Franklin Weng <franklin@goodhorse.idv.tw> Change-Id: If32cdb18c70ec0025c83ba25a99e5d135d66aec9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159193 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2024-01-19Make osl_execProc_test_batch run the new process hiddenMike Kaganski1-1/+1
This prevents a console window flashing briefly on Windows, when runnung the test. Was this way since commit d011896d755252105c740f23f31ed43de64f7c98 (INTEGRATION: CWS sal04 (1.1.2); FILE ADDED, 2003-09-29). Change-Id: I7fb7bb067786d3ad33f9ba831e3b454c91a35e2a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162296 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-12-24Remove unused headers found by bin/find-unusedheaders.shGabor Kelemen1-45/+0
Change-Id: I859138dee575ef7fd76db28b619c673782914782 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161235 Tested-by: Jenkins Reviewed-by: Gabor Kelemen <kelemeng@ubuntu.com>
2023-11-29Extended loplugin:ostr: salStephan Bergmann3-20/+20
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 Bergmann13-1015/+1015
Change-Id: Ic8a02784acb9f8981249689541bb6cba1b7fbfb7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159682 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-11-18c++20: use std::erase(_if) instead of std::remove(_if)+erase (part 7)Julien Nabet1-8/+4
Change-Id: I2a72422a6c8185d17876daac41a86137048b034c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159627 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2023-11-08loplugin:stringstatic, lopluign:ostr (clang-cl)Stephan Bergmann1-2/+2
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 Bergmann1-0/+41
<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 Bergmann5-16/+16
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 Bergmann3-5/+4
...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 Bergmann1-0/+1
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 Bergmann3-39/+35
...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 Bergmann3-16/+16
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 Bergmann2-14/+4
...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 Bergmann1-15/+0
...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 Bergmann2-21/+0
...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 Kelemen43-154/+13
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-14tdf#146619 Remove unused includes from sal/ [headers]Gabor Kelemen1-0/+2
Change-Id: I8fae71e5053950441a2e0920590264c2cb858924 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155546 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-08-07Remove unused header fileGabor Kelemen1-8/+0
Seems like it was committed accidentally Change-Id: Idc086b7b92ef9c4a8b3bafa2114b7da3e8d42618 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155350 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2023-08-07Drop unnecessary header osl_Mutex_Const.hGabor Kelemen2-38/+5
It only contained a single define used in a single file Change-Id: If9f16ab13bb28d2923b97390f1acb013101d0a09 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155349 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-08-04Avoid a Clang template instantiation bug with libstdc++ and C++20Stephan Bergmann1-0/+8
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 Bergmann1-6/+6
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 Bergmann1-1/+3
...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 Bergmann2-0/+6
...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 Bergmann1-3/+3
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 Bergmann2-0/+20
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 Grandin1-4/+4
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 Gilbert4-67/+61
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 Kaganski1-0/+8
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 Kaganski3-6/+6
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 Kaganski2-10/+10
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 Kaganski1-2/+2
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 Rathke1-0/+24
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 Bergmann3-33/+14
...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>
2023-01-27Remove support for AIXStephan Bergmann1-1/+1
As discussed in the mailing list thread starting at <https://lists.freedesktop.org/archives/libreoffice/2023-January/089808.html> "Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*)", the bridge implementation at bridges/source/cpp_uno/gcc3_aix_powerpc is apparently dead and should thus be removed. However, that was the only bridge implementation for AIX, which implies that support for the AIX platform as a whole is dead and should thus be removed. Change-Id: I96de3f7f97d4fd770ff78256f0ea435383688be9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146057 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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-29sal: tweak CppunitTest_sal_osl to run as uid 0Michael Stahl1-3/+30
Change-Id: I280bcc522f3cd375b5f94e644b76bc5f95899324 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133574 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
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>
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-22 13:44:54 +0000