ofz#7322 lcl_MarkEqualByStart sort logic differs from that of operator==

when it encounters a SwPosition with a SwIndex nContent whose m_pIndexReg is
null and compares to one whose m_pIndexReg is not null, where both have an
m_nIndex of 0.

operator== considers them different, while lcl_MarkEqualByStart doesn't care
and sorts them as equal

Change-Id: I29920b98c9e6f395487de1b9cafa6b1282b2b1b6
Reviewed-on: https://gerrit.libreoffice.org/54334
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

1 files changed, 8 insertions, 1 deletions

diff --git a/sw/source/core/doc/docbm.cxx b/sw/source/core/doc/docbm.cxx
index 45618432f67d..65ae2df1c182 100644
--- a/sw/source/core/doc/docbm.cxx
+++ b/sw/source/core/doc/docbm.cxx
@@ -225,6 +225,13 @@ namespace
         return false;
     }
 
+    bool lcl_MarkEqualByStart(const IDocumentMarkAccess::pMark_t& rpFirst,
+                              const IDocumentMarkAccess::pMark_t& rpSecond)
+    {
+        return !lcl_MarkOrderingByStart(rpFirst, rpSecond) &&
+               !lcl_MarkOrderingByStart(rpSecond, rpFirst);
+    }
+
     IDocumentMarkAccess::iterator_t lcl_FindMark(
         IDocumentMarkAccess::container_t& rMarks,
         const IDocumentMarkAccess::pMark_t& rpMarkToFind)
@@ -235,7 +242,7 @@ namespace
         // since there are usually not too many marks on the same start
         // position, we are not doing a bisect search for the upper bound
         // but instead start to iterate from pMarkLow directly
-        while(ppCurrentMark != rMarks.end() && **ppCurrentMark == *rpMarkToFind)
+        while (ppCurrentMark != rMarks.end() && lcl_MarkEqualByStart(*ppCurrentMark, rpMarkToFind))
         {
             if(ppCurrentMark->get() == rpMarkToFind.get())
             {