Fishy assignment in editdoc (editeng) ?

[Stephan Bergmann]

On 26/05/2019 21:24, julien2412 wrote:
> Taking a look to the new reports generated by Cppcheck, I noticed
> "duplicateConditionalAssign" and specifically this code:
>     2028     // If comparing the entire font, or if checking before each
> alteration
>     2029     // whether the value changes, remains relatively the same thing.
>     2030     // So possible one MakeUniqFont more in the font, but as a
> result a quicker
>     2031     // abortion of the query, or one must each time check bChanged.
>     2032     if ( rFont == aPrevFont  )
>     2033         rFont = aPrevFont;  // => The same ImpPointer for
> IsSameInstance
> 
> See
> https://opengrok.libreoffice.org/xref/core/editeng/source/editeng/editdoc.cxx?r=40d25921#2028

 From a quick look, this looks plausible (if the two fonts compare 
equal, but have potentially different innards, make them share a single 
set of innards).

> Another similar place:
> xmlsecurity/source/xmlsec/nss/securityenvironment_nssimpl.cxx
>      800         if( xcert == nullptr ) {
>      801             xcert = nullptr ;  <-- whereas in other parts of the
> same file, we see a throw instruction
>      802         } else {

That was apparently nonsense, <https://gerrit.libreoffice.org/73019> 
"operator new doesn't return null anyway".  Thanks for pointing it out.