summaryrefslogtreecommitdiff
path: root/cppu
AgeCommit message (Collapse)Author
2020-09-13tdf#124176 Use #pragma once in cppu, cppuhelperGeorge Bateman
This commit was carried out by a Python script, source of which is at https://bugs.documentfoundation.org/show_bug.cgi?id=124176#c97. Change-Id: I0b7c5bec8e56bd21e719c8889fe263e377f3b8ca Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102547 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-08-17Remove dead commentStephan Bergmann
...which had been dead ever since b525a3115f54576017a576ff842dede5e2e3545d "initial import" and whose removal has already been suggested in 04bb20f5ad182fd1aa8a4e2e7f569043be8405c1 "Fix typo" Change-Id: I57d1e284e9c38836dca620fd3d0058fc5c6f098e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100854 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-15Fix typoAndrea Gelmini
bDesctructorCalled doesn't exist in the code anymore. I guess we can delete the comment. Change-Id: I551efe2298422e5139f1dd07a6b3bf4728763026 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100774 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-08-05Avoid warnings about unused Char4Stephan Bergmann
Change-Id: Ibcb256552ee03b14a76463be3d9b7ce53213fa7a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100124 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-03loplugin:flatten in configmgr..i18nutilNoel Grandin
Change-Id: Idaeed33df4f1dd1b2acbdaf8a895c5d56c3ca14c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99980 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-07-10replace usage of blacklist with excludelist for IWYUThorsten Behrens
Background and motivation: https://tools.ietf.org/html/draft-knodel-terminology-02 Change-Id: I2f22d455d2a936a85750eaab1fda215ebb6d9d48 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98182 Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-07-01Upcoming improved loplugin:staticanonymous -> redundantstatic: cppuStephan Bergmann
Change-Id: Iac1bd5cb1ff1a1786471b2d8b8a3c500a2e15c5c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97546 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-06-26Handle uno_threadpool_dispose in parallel with uno_threadpool_putJobStephan Bergmann
While tracking down the issue discussed in the commit message of 78dc7d982b65c1843a288b80da83f8766e85d0cf "Remove a potentially already enqueued response when a bridge is disposed", it occurred to me that there should be a race in those uno_threadpool_putJob( bridge_->getThreadPool(), ...); calls in binaryurp/source/reader.cxx, when the bridge gets disposed (through some other thread) between the time the bridge_->getThreadPool() call checks for the bridge being disposed (in which case it would throw a DisposedException) and the actual uno_threadpool_putJob call. I tried to catch that with a previous incarnation of this change (<https://gerrit.libreoffice.org/c/core/+/96120/1> "Jenkins Slides Through the Tiny Window"), but couldn't---presumably because this race would be very rare after all, and the issue I was chasing turned out to be caused by something different anyway. Nevertheless, I wanted to address this potential race now. We can only reliably check for disposed'ness after having locked ThreadPool's m_mutex in uno_threadpool_putJob -> ThreadPool::addJob, but at which time we can no longer indicate this condition to the caller---uno_threapool_putJob is part of the stable URE interface, has a void return type, and should not throw any exceptions as it is a C function. However, if the bridge gets disposed, any threads that would wait for this job (in cppu_threadpool::JobQueue::enter, either from cppu_threadpool::ORequestThread::run waiting to process new incoming calls, or from a bridge's call to uno_threadpool_enter waiting for a respose to an outgoing call) should already learn about the bridge being disposed by falling out of cppu_threadpool::JobQueue::enter with a null return value. So it should be OK if uno_threadpool_putJob silently discards the job in that case. Change-Id: I36fe996436f55a93d84d66cc0b164e2e45a37e81 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96120 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-06-16Use the saner std::condition_variable semantics for JobQueue::m_cndWaitStephan Bergmann
This avoids the need for the tricky osl::Condition::reset calls. For example, the first one (in the "disposed !" case) had been added with 2a3ed89284890615ad4bce57be55ba558351cde1 "sb132: #i112448# proper clean up in JobQueue::enter (patch by olistraub)" as > if( 0 == m_lstCallstack.front() ) > { > // disposed ! > + if( m_lstJob.empty() ) > + { > + osl_resetCondition( m_cndWait ); > + } > break; > } > and then change to > if( 0 == m_lstCallstack.front() ) > { > // disposed ! > - if( m_lstJob.empty() ) > + if( m_lstJob.empty() > + && (m_lstCallstack.empty() > + || m_lstCallstack.front() != 0) ) > { > osl_resetCondition( m_cndWait ); > } with cba3ac1eab7acaf8e6efd7a00eee7c5e969fc49b "Avoid deadlocks when disposing recursive JobQueue::enter", which prevented the reset from ever hapening (because m_lstCallstack.front() cannot both be zero and non-zero here at the same time). The std::condition_variable semantics nicely avoid any reasoning whether or not a reset would be necessary here. Change-Id: Ic9b57b836bb6679829f4aa3b68679256726acf60 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96406 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-06-15Model the dispose tokens as `void const *` instead of `sal_Int64`Stephan Bergmann
...which avoids the sal_IntPtr casts Change-Id: I518fcefc66d297b56c9bd94f7826a44715acb5f5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96392 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-06-15Remove a potentially already enqueued response when a bridge is disposedStephan Bergmann
...while a remote call is in progress. Otherwise, if the same thread later makes another remote call (through another bridge), it would erroneously pair the repsonse for the disposed call with the second call. UITest_calc_demo started to fail that way occasionally, presumably after 77445e201c45e5593761e8399c32f80eea2178a4 "Make Chart Creation Wizard async", but for reasons rather unrelated to the contents of that commit. What apparently happened is that in one test's tearDown, the bridge between the Python and the soffice process happened to be disposed during the XDesktop::terminate call from Python's main thread, so that the response (of type BOOLEAN) remained in the JobQueue. Then during the next test's setUp, XUnoUrlResolver::resolve from Python's main thread would internally make a remote queryInterface call for the initial StarOffice.ComponentContext object, which returns an ANY of either VOID or XInterface type. But that call was then mis-matched with the leftover BOOLEAN response, causing failure. I was able to reproduce that reliably on Linux with a local hack of > diff --git a/cppu/source/threadpool/jobqueue.cxx b/cppu/source/threadpool/jobqueue.cxx > index 6c9324521f40..a87770bf8935 100644 > --- a/cppu/source/threadpool/jobqueue.cxx > +++ b/cppu/source/threadpool/jobqueue.cxx > @@ -71,6 +71,7 @@ namespace cppu_threadpool { > } > > m_cndWait.wait(); > + timespec ms{0, 1000000}; nanosleep(&ms, nullptr); > > struct Job job={nullptr,nullptr}; > { introducing a sleep, so that other threads have a higher chance to dispose the bridge (when the call being processed here is that XDesktop::dispose) after the successful wait() but before the response is processed. UITest_calc_demo then failed with [...] > Execution time for create_chart.CalcChartUIDemo.test_activate_chart: 6.520 > tearDown: calling terminate()... > caught while TearDown: > Traceback (most recent call last): > File "uitest/libreoffice/connection.py", line 127, in tearDown > xDesktop.terminate() > libreoffice.connection.com.sun.star.lang.DisposedException: Binary URP bridge disposed during call binaryurp/source/bridge.cxx:611 > > ok > test_cancel_immediately (create_chart.CalcChartUIDemo) ... [...] > warn:sal.osl.pipe:423851:425076:sal/osl/unx/pipe.cxx:442: recv() failed: ECONNRESET > warn:binaryurp:423851:425076:binaryurp/source/bridge.cxx:843: undisposed bridge "" in state 2, potential deadlock ahead [...] > ====================================================================== > ERROR: test_cancel_immediately (create_chart.CalcChartUIDemo) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "uitest/uitest/framework.py", line 25, in setUp > self.connection.setUp() > File "uitest/libreoffice/connection.py", line 176, in setUp > conn.setUp() > File "uitest/libreoffice/connection.py", line 57, in setUp > self.xContext = self.connect(socket) > File "uitest/libreoffice/connection.py", line 107, in connect > xContext = xUnoResolver.resolve(url) > uno.com.sun.star.uno.RuntimeException: initial object queryInterface for OID "StarOffice.ComponentContext" returned ANY of type boolean binaryurp/source/bridge.cxx:883 [...] Change-Id: Icf9aadbb38e7aafffff844fe8e9ae99e165c1f33 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96326 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-05-24inline some use-once typedefsNoel Grandin
Change-Id: Idddba2f3fd05265b08dbc88edb6152d34a166052 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94730 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-05-08compact namespace in canvas..cuiNoel Grandin
Change-Id: I7bd0c2a55b936896fcfe7e1a374871008a18618f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93706 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-04-28tdf#115399: Don't kill pre-existing typelib_TypeDescription membersStephan Bergmann
...in typelib_typedescription_register, in case they are already being referenced from elsewhere. Instead, only move from *ppNewDescription to pTDR->pType those members that were not yet initialized in the latter. Change-Id: I7620219d137f8dd7f24a0f4a04eda30669b6c5a9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93062 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-04-28Fix printing rtl_uString*Stephan Bergmann
...broken with ef513fd4b049b214a03fbe6e62a5ea43680a7a9b "remove unnecessary use of OString::getStr" Change-Id: I85f5ccb6c5114ea5e3eab43a3c1821292cf4e994 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92993 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-04-23cid#1462311 silence Use after freeCaolán McNamara
etc. revert this hunk of commit 11785217594d863efb518aa8b8f2910cdcb9c59d Date: Tue Apr 14 14:55:22 2020 +0200 loplugin:buriedassign in c* just to silence coverity Change-Id: I6d8819a0ab073a56ab46944b170ef4ae3a28e4d0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92552 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-04-23Related tdf#115399: Reorder code slightlyStephan Bergmann
...in preparation of a forthcoming fix for the issue Change-Id: I6611778dfbc090eb869bf653cf7f61574a81b4f7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92823 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-04-18loplugin:flatten in cppuNoel Grandin
Change-Id: I202698a0310bd26b98c1f744c8f21288f87643f9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92450 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-04-14loplugin:buriedassign in c*Noel Grandin
Change-Id: Id14fed7e5c0f588ad3c927f12251432d12c1a7c8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92190 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-03-06Make TYPELIB_TYPEDESCRIPTIONREFERENCE_ISREALLYWEAK constexprStephan Bergmann
...and make dynamic verifications static where applicable Change-Id: I3fb7ebe6885ee70e493ec1365601a1177d181347 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90002 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-03-04Remove redundant local reallyWeak functionStephan Bergmann
Change-Id: Ica26c0b5a839ebb2ca8ed1e2fa61b70cd08a9278 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89974 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-02-24Fix typoAndrea Gelmini
to complete: https://gerrit.libreoffice.org/c/core/+/89082 Change-Id: I8363f05f15c8d4ef032ccc8d469dc29231d74ca7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89360 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-01-15clang-tidy modernize-concat-nested-namespace in cppcanvas..cppuhelperNoel Grandin
Change-Id: I0bb4ea91288a15fb590d077fb390c53be8b50400 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86801 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-01-07Replace a CPPUNIT_ASSERT_EQUAL with a static_assertStephan Bergmann
Change-Id: I8382aa13eb9c65ae61fc0dbfe440df6718133c18 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/86352 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-18sal_Char->char in cppcanvas..cuiNoel Grandin
Change-Id: I7e9fa7011f1e0bf143f86055718c772caebf8ee6 Reviewed-on: https://gerrit.libreoffice.org/85397 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-12-03Adapt CPPUNIT_ASSERT to C++20 deleted ostream << for sal_Unicode (aka char16_t)Stephan Bergmann
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1423r3.html> "char8_t backward compatibility remediation", as implemented now by <https://gcc.gnu.org/ git/?p=gcc.git;a=commit;h=0c5b35933e5b150df0ab487efb2f11ef5685f713> "libstdc++: P1423R3 char8_t remediation (2/4)" for -std=c++2a, deletes operator << overloads that would print an integer rather than a (presumably expected) character. But for simplicity (and to avoid issues with non-printing characters), keep printing an integer here. Change-Id: I751b99ee32d418eb488131ffa130d6f7d6d38dc7 Reviewed-on: https://gerrit.libreoffice.org/84348 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-23cppcheck: performing init in init list (comphelper/connectivity/cppu/cui)Julien Nabet
Change-Id: I786c2c10e8b37b48adf6d619c0fa6a905de1bf7f Reviewed-on: https://gerrit.libreoffice.org/83584 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2019-11-22Extend loplugin:external to warn about classesStephan Bergmann
...following up on 314f15bff08b76bf96acf99141776ef64d2f1355 "Extend loplugin:external to warn about enums". Cases where free functions were moved into an unnamed namespace along with a class, to not break ADL, are in: filter/source/svg/svgexport.cxx sc/source/filter/excel/xelink.cxx sc/source/filter/excel/xilink.cxx svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx All other free functions mentioning moved classes appear to be harmless and not give rise to (silent, even) ADL breakage. (One remaining TODO in compilerplugins/clang/external.cxx is that derived classes are not covered by computeAffectedTypes, even though they could also be affected by ADL-breakage--- but don't seem to be in any acutal case across the code base.) For friend declarations using elaborate type specifiers, like class C1 {}; class C2 { friend class C1; }; * If C2 (but not C1) is moved into an unnamed namespace, the friend declaration must be changed to not use an elaborate type specifier (i.e., "friend C1;"; see C++17 [namespace.memdef]/3: "If the name in a friend declaration is neither qualified nor a template-id and the declaration is a function or an elaborated-type-specifier, the lookup to determine whether the entity has been previously declared shall not consider any scopes outside the innermost enclosing namespace.") * If C1 (but not C2) is moved into an unnamed namespace, the friend declaration must be changed too, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71882> "elaborated-type-specifier friend not looked up in unnamed namespace". Apart from that, to keep changes simple and mostly mechanical (which should help avoid regressions), out-of-line definitions of class members have been left in the enclosing (named) namespace. But explicit specializations of class templates had to be moved into the unnamed namespace to appease <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598> "explicit specialization of template from unnamed namespace using unqualified-id in enclosing namespace". Also, accompanying declarations (of e.g. typedefs or static variables) that could arguably be moved into the unnamed namespace too have been left alone. And in some cases, mention of affected types in blacklists in other loplugins needed to be adapted. And sc/qa/unit/mark_test.cxx uses a hack of including other .cxx, one of which is sc/source/core/data/segmenttree.cxx where e.g. ScFlatUInt16SegmentsImpl is not moved into an unnamed namespace (because it is declared in sc/inc/segmenttree.hxx), but its base ScFlatSegmentsImpl is. GCC warns about such combinations with enabled-by-default -Wsubobject-linkage, but "The compiler doesn’t give this warning for types defined in the main .C file, as those are unlikely to have multiple definitions." (<https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Warning-Options.html>) The warned-about classes also don't have multiple definitions in the given test, so disable the warning when including the .cxx. Change-Id: Ib694094c0d8168be68f8fe90dfd0acbb66a3f1e4 Reviewed-on: https://gerrit.libreoffice.org/83239 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-11-08Avoid repeated calls cppu::detail::loadModule -> osl_getModuleURLFromAddressStephan Bergmann
...where the latter are reportedly expensive. Both <https://gerrit.libreoffice.org/#/c/75162/> "tdf#121740 related, cache external mapping in cppu::loadExternal" and <https://gerrit.libreoffice.org/#/c/82261/> "tdf#121740 add cache to win osl_getModuleURLFromAddress" attempted to reduce the costs observed when loading one specific document by introducing caches below cppu::detail::loadModule's call to osl::Module::loadRelative. On the other hand, this change reduces the number of calls to osl_getModuleURLFromAddress by computing the base URI in cppu::detail::loadModule only once. For my local Linux --enable-dbgutil build, for `instdir/program/soffice '109340 class14.ppt'` and then exiting LO again (with the document attached at <https://bugs.documentfoundation.org/show_bug.cgi?id=121740#c0>), this reduces the number of calls to osl_getModuleURLFromAddress from 3775 to 22. (Many of those calls originated from cppu::getCaughtException or cppu::throwException, as in osl_getModuleURLFromAddress osl_getModuleURLFromFunctionAddress osl::Module::getUrlFromAddress osl_loadModuleRelative osl::Module::loadRelative cppu::detail::loadModule cppu::loadModule cppu::loadExternalMapping uno_getMapping com::sun::star::uno::Mapping::Mapping cppu::throwException .) Unfortunately, this needs to duplicate functionality from osl_loadModuleRelative (sal/osl/all/loadmodulerelative.cxx) somewhat, as the stable SAL interface only offers functionality to load relative to a given function, not relative to a given base URI. (And extending the stable SAL interface for this one use is not worth the maintenance costs.) Change-Id: Ib58814136d11c67d1419b0224d12e30bb710e613 Reviewed-on: https://gerrit.libreoffice.org/82290 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-28loplugin:stringadd improve detectionNoel Grandin
if one side of the expression is a compile-time-constant, we don't need to worry about side-effects on the other side Change-Id: Iee71ea51b327ef244bf39f128f921ac325d74e2b Reviewed-on: https://gerrit.libreoffice.org/81589 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-10-17Remaining loplugin:bufferaddStephan Bergmann
...that had been missing because the plugin didn't implement postRun, so it didn't report anything when run as part of the shared plugin. (But did report the expected warnings when run as a standalone plugin during CompilerTest_compilerplugins_clang.) Most fixes are straightforward. A noteworthy one is PreparedStatement::setBytes in connectivity/source/drivers/postgresql/pq_preparedstatement.cxx: The old preallocation of a 20 character OStringBuffer might have prevented buf.append( reinterpret_cast<char *>(escapedString), len -1 ); from potentially throwing std::bad_alloc, which would have caused escapedString to be leaked. Even though that 20-character preallocation was likely just random junk and not meant to address the potential leak, lets address it now. Change-Id: Ib506332d061684a22a74e5e39e591539fd2c4900 Reviewed-on: https://gerrit.libreoffice.org/80925 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-15new loplugin:bufferaddNoel Grandin
look for OUStringBuffer append sequences that can be turned into creating an OUString with + operations Change-Id: Ica840dc096000307b4a105fb4d9ec7588a15ade6 Reviewed-on: https://gerrit.libreoffice.org/80809 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-10-14loplugin:stringadd look for unnecessary temporariesNoel Grandin
which defeat the *StringConcat optimisation. Also make StringConcat conversions treat a nullptr as an empty string, to match the O*String(char*) constructors. Change-Id: If45f5b4b6a535c97bfeeacd9ec472a7603a52e5b Reviewed-on: https://gerrit.libreoffice.org/80724 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-10-01loplugin:stringadd in basctl..cuiNoel Grandin
Change-Id: I2fdeb7eb3ead3512ad6d3fe793305038ab3aa7ae Reviewed-on: https://gerrit.libreoffice.org/79886 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-09-03Silence -fsanitize=object-size in --enable-optimized buildsStephan Bergmann
<http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#available-checks> (as of recent LLVM trunk towards LLVM 10) states: "-fsanitize=object-size: An attempt to potentially use bytes which the optimizer can determine are not part of the object being accessed. This will also detect some types of undefined behavior that may not directly access memory, but are provably incorrect given the size of the objects involved, such as invalid downcasts and calling methods on invalid pointers. These checks are made in terms of __builtin_object_size, and consequently may be able to detect more problems at higher optimization levels." A `make check screenshot` with --enabled-optimized runs into two such issues that were not diagnosed with --disable-optimized, in both cases because a struct with an "idiomatic trailing dynamic array member" (statically declared to be an array of size 1) is allocated without any space for that array member, as the dynamic array size is 0 in the specific case: * For > [CUT] sc_ucalc > cppu/source/uno/copy.hxx:46:19: runtime error: member access within address 0x6020001aaa70 with insufficient space for an object of type 'uno_Sequence' (aka '_sal_Sequence') > 0x6020001aaa70: note: pointer points here > 2b 00 80 6a be be be be be be be be 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > ^ > #0 in cppu::allocSeq(int, int) at cppu/source/uno/copy.hxx:46:19 (instdir/program/libuno_cppu.so.3 +0x41f03f) > #1 in uno_type_sequence_reference2One at cppu/source/uno/sequence.cxx:813:20 (instdir/program/libuno_cppu.so.3 +0x41f03f) [...] the call to pNew = allocSeq( 0, 0 ); in uno_type_sequence_reference2One is inlined, so sal_uInt32 nSize = calcSeqMemSize( nElementSize, nElements ); in allocSeq is known to be too small. * For > testSignatureLineODF::TestBody finished in: 2044ms > engine-gpg.c:302:6: runtime error: member access within address 0x604001f24f10 with insufficient space for an object of type 'struct arg_and_data_s' > 0x604001f24f10: note: pointer points here > 6e 01 00 26 be be be be be be be be be be be be be be be be be be be be be be be be be be be be > ^ > #0 in add_data at workdir/UnpackedTarball/gpgmepp/src/engine-gpg.c:302:6 (instdir/program/libgpgme.so.11 +0x120c2b) [...] > make[1]: *** [solenv/gbuild/CppunitTest.mk:114: workdir/CppunitTest/xmlsecurity_signing.test] Error 1 the a = malloc (sizeof *a - 1); is apparently detected to be too small only with optimization enabled. In both cases, the solution is to operate on the too-small dynamically allocated object via a reinterpret_cast'ed pointer to some newly introduced "struct prefix" type. Change-Id: Ie814db1d00a439bb9189474b91d729e538e81984 Reviewed-on: https://gerrit.libreoffice.org/78548 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-08-30new loplugin:noexceptmoveNoel Grandin
idea from mike kaganski look for places where we can mark move operators as noexcept, which makes some STL operations more efficient Change-Id: Id732b89d1fcadd5ceb0ea2b9d159fed06136330f Reviewed-on: https://gerrit.libreoffice.org/78251 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-07-26cid#1448407 silence Resource leakCaolán McNamara
Change-Id: Ida523859077abe5904212db44108fa580bb6c60d Reviewed-on: https://gerrit.libreoffice.org/76355 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-05-22New loplugin:dataStephan Bergmann
...following up on 1453c2c8f13bac64ecd1981af7cebf1c421808ac "prefer vector::data to &vector[0]" Change-Id: I7c113747d92d144a521d49b89384dd8bf1215c01 Reviewed-on: https://gerrit.libreoffice.org/72765 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-04-27tdf#120703 PVS: V581 ifs with identical conditionsMike Kaganski
V581 The conditional expressions of the 'if' statements situated alongside each other are identical. Change-Id: I79c655a072faff0bdb2af031ed1328e684b83aac Reviewed-on: https://gerrit.libreoffice.org/71430 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-04-22Fix typoAndrea Gelmini
Change-Id: I9c69c6e92f04970eada7309969c3016feffcc6e0 Reviewed-on: https://gerrit.libreoffice.org/71056 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2019-04-15improve loplugin simplifyconstructNoel Grandin
to find stuff like OUString s = OUString("xxx") Change-Id: Ie7ed074c1ae012734c67a2a89c564c1900a4ab04 Reviewed-on: https://gerrit.libreoffice.org/70697 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-04-01tdf#120703 PVS: Silence V522 warningsMike Kaganski
V522 There might be dereferencing of a potential null pointer. Change-Id: Ie617b41a8f8d334022cf5313b242a236baedba48 Reviewed-on: https://gerrit.libreoffice.org/70017 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-03-03Simplify containers iterations in cppcanvas, cppu, cppuhelperArkadiy Illarionov
Use range-based loop or replace with STL functions Change-Id: I72bf7cdb632c04e2fc8d4f7ab85cb6571222aa07 Reviewed-on: https://gerrit.libreoffice.org/68636 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-03-02Fix typoAndrea Gelmini
Change-Id: Ib5409a3c9b22bf0caf950905a75559bdef8b057f Reviewed-on: https://gerrit.libreoffice.org/68612 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2019-02-20More loplugin:simplifyboolStephan Bergmann
...found with (trunk) libc++ on macOS, where the standard library iterator implementations are apparently sufficiently different to libstdc++ to find more cases of !(... == ...) vs. ... != ... Change-Id: Ia3861406aa584c7b1d33f47448190b5cf2e770f7 Reviewed-on: https://gerrit.libreoffice.org/68089 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-02-19Some uses of C++17 class template argument deductionStephan Bergmann
Change-Id: I47c469c0fcdff41d83729be9489c946e81ef3686 Reviewed-on: https://gerrit.libreoffice.org/68020 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-02-19More loplugin:simplifyboolStephan Bergmann
...found with GCC 9, where the standard library iterator implementations are apparently sufficiently different to older versions of GCC to find more cases of !(... == ...) vs. ... != ... Change-Id: Ibe7c5140049a69d2c5318b4b2371f2e66bd05028 Reviewed-on: https://gerrit.libreoffice.org/68012 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-02-08loplugin:indentation in cppu..cuiNoel Grandin
Change-Id: If625e5bf38ca8e1f12686038c7c9be8d0303b6f6 Reviewed-on: https://gerrit.libreoffice.org/67536 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2019-01-29cppu: fix Android buildMiklos Vajna
By restoring includes which are still needed, conditionally. Change-Id: Icc331c7d6a084af7d93b941ea879f0c60b9ca9f3
2019-01-29tdf#42949 Fix IWYU warnings in cppu/Gabor Kelemen
Found with bin/find-unneeded-includes Only removal proposals are dealt with here. Change-Id: Ia1b2f0a9c99acc7ac538f3b41c1b6757d414db35 Reviewed-on: https://gerrit.libreoffice.org/66970 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
generated by cgit (git 2.34.1) at 2024-12-26 11:19:14 +0000