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;
-    }
 }
 
 }

Reply via email to