<html>
<head>
<base href="https://bugs.documentfoundation.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_UNCONFIRMED "
title="UNCONFIRMED - Make use of SfxPoolItems more typesafe by using StaticWhichCast"
href="https://bugs.documentfoundation.org/show_bug.cgi?id=140226">140226</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Make use of SfxPoolItems more typesafe by using StaticWhichCast
</td>
</tr>
<tr>
<th>Product</th>
<td>LibreOffice
</td>
</tr>
<tr>
<th>Version</th>
<td>Inherited From OOo
</td>
</tr>
<tr>
<th>Hardware</th>
<td>All
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>UNCONFIRMED
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Component</th>
<td>Writer
</td>
</tr>
<tr>
<th>Assignee</th>
<td>libreoffice-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>bjoern.michaelsen@libreoffice.org
</td>
</tr></table>
<p>
<div>
<pre>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: <a href="https://gerrit.libreoffice.org/c/core/+/110233">https://gerrit.libreoffice.org/c/core/+/110233</a>
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:
.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>