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.