https://bugs.documentfoundation.org/show_bug.cgi?id=99643
Michael Stahl <mst...@redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |d.ostrov...@gmx.de
Resolution|--- |FIXED
Assignee|libreoffice-b...@lists.free |mst...@redhat.com
|desktop.org |
Whiteboard|target:5.3.0 |
--- Comment #15 from Michael Stahl <mst...@redhat.com> ---
it breaks when retrieving the UNO service manager via
OneInstanceOleWrapper_Impl::CreateInstance()
okay so technically this commit "broke" it
commit 120586bb305f7bd763753a3f5a8d60e25ad3db8f
Author: David Ostrovsky <da...@ostrovsky.org>
AuthorDate: Sat Feb 20 16:47:26 2016 +0100
Commit: Michael Stahl <mst...@redhat.com>
CommitDate: Mon Feb 29 13:05:33 2016 +0100
Ole: Fix WaE
specifically this change:
@@ -488,7 +488,7 @@ Any SAL_CALL InterfaceOleWrapper_Impl::createBridge(const
Any& modelDepObject,
pVar->pdispVal= static_cast<IDispatch*>( this);
AddRef();
- retAny<<= reinterpret_cast< sal_uInt32 >( pVar);
+ retAny<<= reinterpret_cast< sal_uIntPtr >( pVar);
}
}
}
because the caller of that function stupidly hard-codes an expected return type
of TypeClass_UNSIGNED_LONG, which is sal_uInt32, but on a 64-bit platform
sal_uIntPtr of course corresponds to TypeClass_UNSIGNED_HYPER.
of course the pVar is not at all guaranteed to have its thrown-away upper bits
all 0 in a 64-bit build, so if this worked in 5.0 it is purely by luck.
fixed on master, by adapting the caller to expect hyper instead, plus fixing up
several other callers and implementations of createBridge().
actually i checked again and *both* of the 64-bit pointer fixes mentioned in
comment #12 are already in 5.1, so nothing more to backport.
--
You are receiving this mail because:
You are the assignee for the bug._______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
