include/svtools/asynclink.hxx | 6 ------ svtools/source/control/asynclink.cxx | 15 --------------- 2 files changed, 21 deletions(-)
New commits: commit 31c071c72b40194778742ec3fb7e919aebb20c02 Author: Stephan Bergmann <sberg...@redhat.com> AuthorDate: Fri Jan 28 15:01:31 2022 +0100 Commit: Caolán McNamara <caol...@redhat.com> CommitDate: Sat Feb 5 22:45:32 2022 +0100 We no longer know how to contact TLX anyway GCC 12 trunk started to warn > svtools/source/control/asynclink.cxx: In member function ‘void svtools::AsynchronLink::HandleCall_PostUserEvent(void*)’: > svtools/source/control/asynclink.cxx:76:15: error: storing the address of local variable ‘bDeleted’ in ‘*this.svtools::AsynchronLink::_pDeleted’ [-Werror=dangling-pointer=] > 76 | _pDeleted = &bDeleted; > | ~~~~~~~~~~^~~~~~~~~~~ > svtools/source/control/asynclink.cxx:75:10: note: ‘bDeleted’ declared here > 75 | bool bDeleted = false; > | ^~~~~~~~ > svtools/source/control/asynclink.cxx:75:10: note: ‘<unknown>’ declared here And while that is arguably a false warning, it points at some dubious code anyway: The only reason for the AsynchronLink _bInCall and _pDeleted members is to potentially SAL_INFO some "valuable historical artefact", if AsynchronLink::Call were ever called recursively. But 0de7513cd73f1f35265e42f9a2b9befe81302c2c "osl::Mutex->std::mutex in AsynchronLink" apparently already argued that such recursive calls can never happen, as locking _aMutex in a recursive call of Call would now deadlock. Change-Id: I9ee47ac65652e40e23a37be3d0694fa1185b877a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129104 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sberg...@redhat.com> (cherry picked from commit a4348ec796e6efe0edce7bb8bfa47b1fa95d0e34) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129445 Reviewed-by: Caolán McNamara <caol...@redhat.com> diff --git a/include/svtools/asynclink.hxx b/include/svtools/asynclink.hxx index 3a699fe46a14..ae5139e3206b 100644 --- a/include/svtools/asynclink.hxx +++ b/include/svtools/asynclink.hxx @@ -34,8 +34,6 @@ class UNLESS_MERGELIBS(SVT_DLLPUBLIC) AsynchronLink { Link<void*,void> _aLink; ImplSVEvent* _nEventId; - bool _bInCall; - bool* _pDeleted; void* _pArg; std::mutex _aMutex; @@ -45,14 +43,10 @@ public: AsynchronLink( const Link<void*,void>& rLink ) : _aLink( rLink ) , _nEventId( nullptr ) - , _bInCall( false ) - , _pDeleted( nullptr ) , _pArg( nullptr ) {} AsynchronLink() : _nEventId( nullptr ) - , _bInCall( false ) - , _pDeleted( nullptr ) , _pArg( nullptr ) {} ~AsynchronLink(); diff --git a/svtools/source/control/asynclink.cxx b/svtools/source/control/asynclink.cxx index 1fb8b613eb09..08fc755c7862 100644 --- a/svtools/source/control/asynclink.cxx +++ b/svtools/source/control/asynclink.cxx @@ -30,7 +30,6 @@ namespace svtools { void AsynchronLink::Call( void* pObj, bool bAllowDoubles ) { - SAL_INFO_IF( !_bInCall, "svtools", "Recursives Call. Eher ueber Timer. TLX Fragen" ); // Do NOT translate. This is a valuable historical artefact. if( !_aLink.IsSet() ) return; @@ -47,8 +46,6 @@ AsynchronLink::~AsynchronLink() { Application::RemoveUserEvent( _nEventId ); } - if( _pDeleted ) - *_pDeleted = true; } void AsynchronLink::ClearPendingCall() @@ -69,19 +66,7 @@ IMPL_LINK_NOARG( AsynchronLink, HandleCall_PostUserEvent, void*, void ) // need to release the lock before calling the client since // the client may call back into us } - _bInCall = true; - - // some fancy footwork in case we get deleted inside the call - bool bDeleted = false; - _pDeleted = &bDeleted; - _aLink.Call( _pArg ); - - if( !bDeleted ) - { - _bInCall = false; - _pDeleted = nullptr; - } } }