[Libreoffice-bugs] [Bug 140226] New: Make use of SfxPoolItems more typesafe by using StaticWhichCast
bugzilla-daemon at bugs.documentfoundation.org
bugzilla-daemon at bugs.documentfoundation.org
Sun Feb 7 00:52:43 UTC 2021
https://bugs.documentfoundation.org/show_bug.cgi?id=140226
Bug ID: 140226
Summary: Make use of SfxPoolItems more typesafe by using
StaticWhichCast
Product: LibreOffice
Version: Inherited From OOo
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: Writer
Assignee: libreoffice-bugs at lists.freedesktop.org
Reporter: bjoern.michaelsen at libreoffice.org
Description:
There is a lot of code of the form:
switch ( rItem.Which() )
{
case RES_CHRATR_CASEMAP:
rFnt.SetCaseMap( static_cast<const
SvxCaseMapItem&>(rItem).GetCaseMap() );
break;
...
in Writer and elsewhere. That is: code that uses SfxPoolItems home-grown
"WhichId" as type information and then uses a static_cast to downcast the base
class to a proper type. As this "WhichId" is generated at runtime, this is
errorprone and fragile. Since the introduction of TypedWhichId in
include/svl/typedwhich.hxx (Thanks Noel!), there exists a proper mapping of
WhichIds to the derived classes of SfxPoolItem. SfxPoolItem::StaticWhichCast
uses these to do a proper downcast, while asserting if either the WhichId or
the dynamic type does not match expectations. This EasyHack is to:
1/ Find such a static_cast. "git grep static_cast.*Item" might be a starting
point.
2/ Replace the static_cast with a StaticWhichCast. An example of how this is
done
can be found at: https://gerrit.libreoffice.org/c/core/+/110233
3/ Ensure the debug builds still pass all tests after the change
(gerrit/jenkins
can help here.)
What is to be done, if one of the StaticWhichCasts asserts? Congratulations,
you likely just dicovered some type confusion in LibreOffice. You now have
three options to resolve this issue:
a/ Investigate how the misleading item ended up in this place and fix it. This
might be non-trivial.
b/ Put a big, fat FIXME note in the source code hinting that the content of the
SfxPoolItem defies expectations, use a DynamicWhichCast instead and guard
the
following code against the case that the cast produces a nullptr.
c/ Leave this particular static_cast as is and ad a big, fat FIXME not as per
above.
Ultimately, a/ is the best option here, but it might be out of the scope of an
EasyHack. If you have help available (e.g. from #libreoffice-dev IRC), you
might still venture to solve it.
Steps to Reproduce:
.
Actual Results:
.
Expected Results:
.
Reproducible: Always
User Profile Reset: No
Additional Info:
.
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20210207/5e23ee84/attachment.htm>
More information about the Libreoffice-bugs
mailing list