FYI, I also decided to start doing the iOS builds using clang.
Whoa, compiling with Clang really reveals some interesting
thinko-style bugs in the code. Bugs so old that it is hard to say
whether it is riskier to fix them and better to let the code be as is
(and work as it has worked all the time) even if it actually does
something different than what the author might originally have
intended.
Like this:
--- a/sw/source/filter/ww8/ww8par3.cxx
+++ b/sw/source/filter/ww8/ww8par3.cxx
@@ -2466,7 +2466,7 @@ static void lcl_AddToPropertyContainer
uno::Any aAny(C2U(""));
xPropContainer->addProperty
(rPropertyName,
- static_cast<sal_Int16>(beans::PropertyAttribute::BOUND ||
+ static_cast<sal_Int16>(beans::PropertyAttribute::BOUND |
beans::PropertyAttribute::REMOVABLE),
aAny);
}
I.e. the code has until now passed the result of a *logical* OR or two
non-zero values, i.e. the value 1, which is
beans::PropertyAttribute::MAYBEVOID, even if the author presumably
wanted the *bitwise* OR of the two attribute bits.
So if this is code that actually is invoked now and then, and hasn't
caused any bugs (?), is it then risky to "fix" it? (Well, I did fix it
anyway.)
--tml
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.