summaryrefslogtreecommitdiff
path: root/sal
AgeCommit message (Collapse)Author
2021-08-27Fix this FIXMEMike Kaganski
Change-Id: I4449d3c87adbcb94c721799aa6de1d615eb7041f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121070 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-08-27Use PSAPI functionality directlyStephan Bergmann
Dynamically trying to obtain the two PSAPI functions was apparently originally done because "This version can fail because PSAPI.DLL is not always part of NT 4 despite MSDN Libary 6.0a say so", according to the comment added with 961512bd9ae008fdd8ab5cdf1ba6b5d25ffb0429 "#94875# Added additional method (for NT4) to determine the module containing an address". (That comment was removed again in 515d2579d305a6127c6c194319a58eac62437e33 "Replace legacy dynamically- loaded functions with statically linked ones", which curiously left the dynamic loading of PSAPI.DLL in place there, though.) <https://docs.microsoft.com/en-us/windows/win32/api/psapi/nf-psapi-enumprocessmodules> states that the PSAPI functionality is available in "Kernel32.dll on Windows 7 and Windows Server 2008 R2; Psapi.dll (if PSAPI_VERSION=1) on Windows 7 and Windows Server 2008 R2; Psapi.dll on Windows Server 2008, Windows Vista, Windows Server 2003 and Windows XP". I do not find any mention of PSAPI_VERSION across our code base, so assume that PSAPI_VERSION=1 would be some legacy mode that we do not use, so with our baseline of Windows 7 (cf. README.md), relying on the PSAPI functionality being available without adding anything specific to gb_Library_use_system_win32_libs,sal should presumably be OK. Change-Id: I55ab29be2a3ee3984c6987e953819cb2e92e4aa8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121136 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-08-20New loplugin:unusedcapturedefaultStephan Bergmann
In sc/qa/unit/ucalc_formula.cxx, dropping the capture-default from the lExpectedinF lambda revealed that MSVC in C++17 mode (i.e., when building without --with-latest-c++) requires ROW_RANGE (a local const int variable from the enclosing TestFormula::testTdf97369) to be captured, even though all uses of that variable within the lambda body are constant expressions. That is still true at least for the latest Visual Studio 2019 version 16.11.1. (This is not an issue for the lExpectedinH and lExpectedinI lambdas a few lines further down, as they, in addition to using that ROW_RANGE, also use the local const double variables SHIFT1 and SHIFT2, whose uses are not constant expressions, so they are implicitly captured and loplugin:unusedcapturedefault does not suggest dropping those lambdas' capture-defaults in the first place.) Change-Id: Iee7efb485187cbe8eba6a2d470afca4993eb1816 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120693 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-08-18GCC bug 96878 is fixed in upcoming GCC 12Stephan Bergmann
However, restricting the workaround to GCC <= 11 then revealed that some old versions of Clang apparently had a similar issue, causing "error: use of class template 'OStringLiteral' requires template arguments; argument deduction not allowed here", and thus also need the workaround. I saw the non-workaround code fail with a build of Clang 6.0.0 and succeed with a build of Clang 7.0.0. Change-Id: I6e4cf6c8c3a11618a578401574e5679e6b65d7f4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120657 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-08-02display stack trace on assert for windows jenkins buildsNoel Grandin
Change-Id: I1c23fda56c013eeeaf4ad1099c164d6d1146f68b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119851 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-07-31rtl::Static -> static localNoel Grandin
in a handful cases, like a map or a vector, we don't need init on demand at all, the default constructor can be laid out at compile time Change-Id: Ifa3188af7a65cd475ce0f603d15a8c26bcda7e6d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119710 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-07-29Fix typosAndrea Gelmini
Change-Id: I0430fe4bc3107b321e7b7ab84cbc3e6afff97372 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119647 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-07-28log access violation on windows tinderboxenNoel Grandin
where we currently have no good feedback when something goes wrong. Credit: Exception printing code written by msdn-whiteknight as seen at https://stackoverflow.com/questions/22467604/how-can-you-use-capturestackbacktrace-to-capture-the-exception-stack-not-the-ca Change-Id: I44c65b10c0b0151c3236521d62a824570d4cdccf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119561 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-07-27[API CHANGE] Drop obsolete osl_demultiplexSocketEvents et alStephan Bergmann
...which were deprecated in 0a126b4c661d65860fd2de92f8cc49bdb65a957c "Deprecate osl_demultiplexSocketEvents et al" towards LO 7.2 (and leave aborting stubs in place for backwards compatibility) Change-Id: Ice6032eb2f351af87dd56eecb002aa2a91e79373 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119560 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-07-23no need to allocate these static vars on demandNoel Grandin
the constructor can be laid out at compile/link time Change-Id: I377a537e15199ae81394d76ac662576280a25c25 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119362 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-07-21Use existing rtl_math_stringToDoubleStephan Bergmann
...like it is also already done in LineParser::readDouble in sdext/source/pdfimport/wrapper/wrapper.cxx (esp. since the code should be changed to use C++17 std::from_chars once that is available in all our baselines), reverting again the introduction of rtl_str_toDouble_WithLength in b1df9c67349cf4cc5be4128d797aefb87f50e38f "[API CHANGE] reduce cost of numeric conversion" Change-Id: If7e3a15649f80093d3407157412fd3deb3a38b12 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119318 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins
2021-07-21Use existing rtl_str_toInt64_WithLengthStephan Bergmann
...like it is also already done in LineParser::readInt32 in sdext/source/pdfimport/wrapper/wrapper.cxx (esp. since the code should be changed to use C++17 std::from_chars once that is available in all our baselines), reverting again the introduction of rtl_str_toInt32_WithLength in b1df9c67349cf4cc5be4128d797aefb87f50e38f "[API CHANGE] reduce cost of numeric conversion" Change-Id: I2789f8ec55c8d89150d1c68e6b353a1d2e1d1703 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119301 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins
2021-07-17[API CHANGE] reduce cost of numeric conversionNoel Grandin
on a hot path, since we already know the length of these strings. Which requires adding some new variants of our string conversion functions Change-Id: I1877f8f3c72934c07f14eec7e73bbe8d7b0f1808 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119065 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-07-09Do not support +/-NaN with an explicit signStephan Bergmann
The code accepting "NaN" had been introduced with 92dafe9862d693ce9d79269627c3e6832422874e "dba33h: #i112652#: rtl/math.h: string<->double conversion and XMLSchema-2: [...] rtl_math_stringToDouble and rtl_math_uStringToDouble support XMLSchema-2 values in addition to deprecated previously supported values." The "XMLSchema-2" mentioned in that commit and in the corresponding <https://bz.apache.org/ooo/show_bug.cgi?id=112652> "ORB: report builder not handle correctly NULL values" presumably references <https://www.w3.org/TR/xmlschema-2/> "XML Schema Part 2: Datatypes Second Edition", where section "3.2.5 double" only supports "NaN" without a "+" or a "-" sign in the lexical representation. So stop accepting those. (I came across this in the context of 2b2b6405161025678f91a5625e50d0b414597368 "Reliably generate positive or negative NaN again", wondering whether this code should be updated too. But then decided that it is probably best not to allow that non-standard signed NaN notation for this case, and just keep producing for the "NaN" representation whatever std::numeric_limits<double>::quiet_NaN produces.) Change-Id: I035e78ca36240317f72f117d2b456fc474d8c08a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118647 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-07-09loplugin:indentation (clang-cl)Stephan Bergmann
Change-Id: Iae559ca8bee9650c01167a4d1b918e18cbf03c28 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118660 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-07-08Reliably generate positive or negative NaN againStephan Bergmann
...after e5c80bb69a30dfb0a3daf6061ab127d92f8142d6 "Purge out setNan from math.cxx" had dropped the use of rtl::math::setNan and sign bit fiddling, and relied on the implicit assumption that std::numeric_limits<double>::quiet_NaN would produce a positive NaN (but which does not seem to be guaranteed by the C++ standard) and on the expressed hope that multiplying such a positive NaN by -1 would generate a negative NaN (but which does not seem to be guaranteed by IEEE 754: while it mandates that a NaN's payload is preserved across such an operation, the result's sign bit appears to be unspecified) Change-Id: I12215c888a1cb8de6b3f046a836c550cb21b5a85 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118604 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-07-04Remove unused includesBaiXiaochun
Change-Id: I243d2998725f09ef533bd06865081d5c415f0d18 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118282 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-07-02Purge out setNan from math.cxxBaiXiaochun
Change-Id: I95f9b37b564bb733f44899a8c6c1ea3c36e35694 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118196 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-06-29Simplify expresionBaiXiaochun
Reduce operation count by space / speed tradeoff. This expression is widely used in LO. Then needs to be fast. Change-Id: Ic88cf15d451ec95a8ad6da88cd9f601cf2876871 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117954 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
2021-06-28loplugin:indentation improve checks for brace alignmentNoel Grandin
Change-Id: I333100fda7e181f68f36b03279b3fbb8cb768310 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117615 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-06-21tdf#135316 add small cache to rtl_bootstrap_args_openNoel Grandin
Filesystem access is quite expensive on Windows, so add a small cache for the filepath/name normalisation. This takes my load time from 19s to 18s Change-Id: I4410d066b8a4d2fd2eb746a5dd8f4ee763a8aa3e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117549 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-06-21remove now unnecessary commentNoel Grandin
Change-Id: I0297f299c42a5ce5485cdcdebfbd1597969c907c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117573 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-06-21simplify bootstrap_map (tdf#135316 related)Noel Grandin
No need for this indirection Change-Id: I87c90c9f1a7904f5a506acac631fe5a1f52f9190 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117521 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-06-18Use std::fesetround / std::nearbyint for half-to-even roundingMike Kaganski
C++ floating-point environment has thread storage duration, so std::fesetround call is thread-safe. std::nearbyint uses half-to-even rounding with FE_TONEAREST, as specified in ISO/IEC 9899:1999 F.3, and in Appendix to ANSI/IEEE 854. Change-Id: I26995842c30e2663b40af5b5314791c1328037d4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117307 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-06-16Adapt implicit OString return value construction to C++23 P2266R1Stephan Bergmann
With the recent implementation of <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2266r1.html> "P2266R1: Simpler implicit move" in Clang 13 trunk as <https://github.com/llvm/llvm-project/commit/bf20631782183cd19e0bb7219e908c2bbb01a75f> "[clang] Implement P2266 Simpler implicit move", a --with-latest-c++ build started to fail with > comphelper/source/xml/xmltools.cxx:103:20: error: no viable conversion from returned value of type 'char [39]' to function return type 'rtl::OString' > return str; > ^~~ [...] > include/rtl/string.hxx:277:5: note: candidate constructor [with T = char [39]] not viable: expects an lvalue for 1st argument > OString( T& value, typename libreoffice_internal::NonConstCharArrayDetector< T, libreoffice_internal::Dummy >::Type = libreoffice_internal::Dummy() ) > ^ [...] etc. Change-Id: If34f143a1855fdd7cd22ea3d7594f9381d50a7ec Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117336 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-06-02Make optional use of SetThreadDescription in osl_setThreadNameMike Kaganski
... so that thread name could appear in crash dumps, and be potentially available for logging on Windows 10 version 1607 and later. Change-Id: I176ca1fce57e0532a226f85836b3889a8ffb2984 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116462 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-06-02Revert "sb138: #i115619# fix for MinGW"Mike Kaganski
This reverts commit 6727dc5d9414e77975b9fd765993c6e207f872f3. We now don't support compiling using MinGW. Change-Id: I0dee00780bfb4b7deceddd8cd30af03b7f7ed212 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116591 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-06-01fix leak in SocketTestNoel Grandin
Change-Id: I8c5e2d4c4687beab08876fe3e945d19a1629bc36 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116514 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-05-31Replace inet_addr with inet_ptonStephan Bergmann
...as inet_addr is deprecated (it does not allow to distinguish successful return for "255.255.255.255" from -1 error return); and update tests Change-Id: I605cb2ba18fe9bd11d2d68c8f1c94271c4503509 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116441 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-05-31Replace inet_ntoa with inet_ntopStephan Bergmann
...as inet_ntoa is potentially not thread-safe; and add a test Change-Id: I9df945b006ba7194c3b1444c4886101c08339ad0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116425 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-05-26Replace a use of select with pollStephan Bergmann
...to avoid undefined behavior with file descriptors >= FD_SETSIZE (cf. 0a126b4c661d65860fd2de92f8cc49bdb65a957c "Deprecate osl_demultiplexSocketEvents et al") Change-Id: I168072b50efc5d50ee3767d0b56be4a8ffa12924 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116119 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-05-23Related: tdf#136794 tdf#137063 Unlimit decimals in rtl_math_round()Eike Rathke
Change-Id: I7f9fb45824458d578ee302a668386fe0c3c80974 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116010 Reviewed-by: Eike Rathke <erack@redhat.com> Tested-by: Jenkins
2021-05-21Lets assume general availability of POSIX poll.hStephan Bergmann
...which should have been first released in SuS Issue 4, Version 2 in 1995. If there should still be any relevant platforms that provide the functionality only in a non-standard header, please add back the relevant #if'ery. Change-Id: I0f55341d24b905161ec38ed0d52602c6b6dfac46 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115888 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-05-18Replace rtl_string_getTokenView with o3tl::getTokenStephan Bergmann
...to not needlessly extend the sal ABI. At least for now, o3tl::getToken has a simpler interface than its OString::getToken counterpart (driven mainly by how it is used for now): it does not support a `token` argument, and its `position` argument must not be npos. To meet the latter requirement, the check for "subpath" in LineParser::readPath has been reworked slightly. Change-Id: I4428fe2d9aa03ca83a436fc6493fbc34665a8033 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115742 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-05-18update "add OString::getTokenView"Noel Grandin
update commit 3669d4ec43a6aa2d410d8351d631548db45a5302 Date: Fri May 14 15:51:38 2021 +0200 add OString::getTokenView (tdf#42374 related) with suggested changes from gerrit review Change-Id: I861d960deaa010740a4aa964e402c4c76a85cbc7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115706 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-05-15add OString::getTokenView (tdf#42374 related)Noel Grandin
small improvement to PDF import no need to construct temporary string objects when we are just to going to convert them into int/double. So use a view and convert the data through the view. Change-Id: I824fe88bf17142b48fe6032e10c0f3a111927e96 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115616 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-05-14Improve loplugin:stringviewStephan Bergmann
Issue the "instead of O[U]String, pass [u16]string_view" diagnostic also for operator call arguments. (The "rather than copy, pass subView()" diagnostic is already part of handleSubExprThatCouldBeView, so no need to repeat it explicitly for operator call arguments.) (And many call sites don't even require an explicit [u16]string_view, esp. with the recent ad48b2b02f83eed41fb1eb8d16de7e804156fcf1 "Optimized OString operator += overloads". Just some test code in sal/qa/ that explicitly tests the O[U]String functionality had to be excluded.) Change-Id: I8d55ba5a7fa16a563f5ffe43d245125c88c793bc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115589 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-05-05WASM: add initial support for Emscripten cross buildJan-Marek Glogowski
- configure with: - --host=wasm64-local-emscripten - had to make a few externals optional, so adding: - --disable-nss - --disable-cmis - --disable-curl Change-Id: I48d1c73d2675ad2e2beaf2c341578199efbd24ee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111130 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2021-04-28Add API to LibreOfficeKit to set arbitrary run-time options in coreTor Lillqvist
Add setOption(const char*, const char*) At the moment this enables starting and stopping the ProfileZone event recording and overriding the SAL_LOG environment variable. Change-Id: Ic3a934bb4246c755a91eee8a8343fafc15815116 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114439 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114559 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114656 Tested-by: Tor Lillqvist <tml@collabora.com>
2021-04-28loplugin:stringviewparam (clang-cl)Stephan Bergmann
Change-Id: I3cf85911785f2c03255869f505e5b86ad2fd9c74 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114690 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-04-27loplugin:stringadd (clang-cl)Stephan Bergmann
Change-Id: Id7c2db4abcf947c4efa0296df29feca2c36d3cf8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114692 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-04-27loplugin:nullptr (clang-cl)Stephan Bergmann
Change-Id: I3c0ee11c42a2a4a22adf894341b04a229d579226 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114689 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-04-23Step 1 of removing cargo-cult pragma pack around rtl_[u]StringStephan Bergmann
Following up on f62cb40bdfaf41cf8e989640f9be79f652f30914 "Remove dubious #pragma pack" and 9eba8aa38db3a0dc2f7dfaf24a003c16418aef18 "Remove dubious #pragma pack" for O[U]StringLiteral, which argued that the pragma pack around rtl_[u]String are useless cargo cult (paraphrasing): "All struct member types involved (oslInterlockedCount aka sal_Int32, sal_Int32 itself, sal_Unicode, and char) have size <= 4 resp. < 8, so the member alignment ("on a boundary that's either a multiple of [the pragma pack value], or a multiple of the size of the member, whichever is smaller", according to <https://docs.microsoft.com/en-us/cpp/preprocessor/pack?view=msvc-160>) is not affected. And neither are alignof(rtl_String) and alignof(rtl_uString) affected, which would remain e.g. 4 on x86-64." (Curiously, the pragma pack value had always been 8 for rtl_String but 4 for rtl_uString, ever since at least 9399c662f36c385b0c705eb34e636a9aec450282 "initial import".) The plan is as follows: In step 1, add temporary static_asserts that state the current alignof/sizeof values; keep this for a while to see that all relevant Windows builds actually agree on these status-quo values. In step 2, remove the pragma pack cargo cult; keep the static_asserts for a while to see that the removal has no impact on any of the relevant Windows builds. Finally, in step 3, remove the temporary static_asserts again. Change-Id: I8059ac300cc5b517db4a575f0eaba48678966537 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114540 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-04-21loplugin:stringadd replace OUStringLiteral temporaries with OUString::ConcatNoel Grandin
Change-Id: I656f06a74d9f0180ae460264563d6a935c7d2c60 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114377 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-04-21Simplify some code by using OUString instead of raw rtl_uStringStephan Bergmann
Change-Id: I0d795db2e0fc5f5a74fd8437cac46edaabd1336d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114342 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-04-21Simplify some code by using OUString instead of raw rtl_uStringMike Kaganski
Mimic 277554987fcd697c14f348f05e5e378d1db77ad5 in Win code Change-Id: Ibef0d7e1f267e4d3b56ebd051e8016ceefbee008 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114349 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-04-20Simplify some code by using OUString instead of raw rtl_uStringStephan Bergmann
Change-Id: I62001c05436efe6a5fb6f19fb733e41837c7d9d7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114341 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-04-20Simplify some code by using OUString instead of raw rtl_uStringStephan Bergmann
Change-Id: I5a5dea23a466c0da12376f8b916b1a1b0eb0bd36 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114340 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-04-20Remove obsolete commentStephan Bergmann
...which was already obsolete at least back in 84c4489cb7da4a9a600d102267f589b4a0419b4c "#104563#moved parts of file.c into separate files" (where the hack had already been commented out) and should have been removed in e7982510d23c4b6047f0b81bfe1c684ecb1fff8a "osl: cleanup file_url.cxx" (which removed the commented-out code) Change-Id: I9fed1c594ff5180979bab7f3f8d7808c941a4ea8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114330 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-04-19flatten some codeNoel Grandin
Change-Id: I1b3148b1330b3713b1f158bf15c3e247c6982928 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114269 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
generated by cgit (git 2.34.1) at 2024-07-12 04:23:09 +0000