[Libreoffice-bugs] [Bug 140226] New: Make use of SfxPoolItems more typesafe by using StaticWhichCast

[bugzilla-daemon at bugs.documentfoundation.org]

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>