[Libreoffice-commits] core.git: sc/source

[Stephan Bergmann (via logerrit)]

 sc/source/filter/ftools/fprogressbar.cxx |   10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

New commits:
commit 4fc0184aede43a48b458d1ecd2b9d07e8aa80d25
Author:     Stephan Bergmann <sbergman at redhat.com>
AuthorDate: Fri Nov 20 08:06:40 2020 +0100
Commit:     Stephan Bergmann <sbergman at redhat.com>
CommitDate: Fri Nov 20 11:50:32 2020 +0100

    Adapt ScfProgressBar to SfxProgress::SetState taking sal_uInt32
    
    ...since 5a6ab81651a98dd726ab7d40101dc81f62895fd4 "tdf#75280 Cleaning up of
    sal_uIntPtr usage #2".  mnSysProgressScale had been introduced with
    2a7add76241d8a3de05e3d26689a2d16d8b92913 "INTEGRATION: CWS dr20", which mentions
    "2004/06/17 14:58:21 dr 1.3.320.2: #i27407# handle limit of SfxProgress
    (ULONG_MAX/100)" though the referenced
    <https://bz.apache.org/ooo/show_bug.cgi?id=27407> "Save default row format to
    decrease Excel file size" does not appear to directly mention any reason for
    this particular change.  However, prior to
    dbdc29e499abf125b6d6f66de668bc60c88fe599 "INTEGRATION: CWS toolbars2"
    SfxProgress::SetState did contain code that multiplied the passed-in value (back
    then of type ULONG) by 100, so it appears mnSysProgressScale was meant to
    mitigate that.  So even if the original motivation for mnSysProgressScale is
    gone, repurpose it to address the mismatch between std::size_t (as meanwhile
    used throughout ScfProgressBar) and sal_uInt32 (as meanwhile used throughout
    SfxProgress).
    
    Change-Id: I1448bcd7521c87079bc4e9afc5f2d9951fc67aee
    Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106216
    Tested-by: Jenkins
    Reviewed-by: Stephan Bergmann <sbergman at redhat.com>

diff --git a/sc/source/filter/ftools/fprogressbar.cxx b/sc/source/filter/ftools/fprogressbar.cxx
index b46f36027e8c..89301c14da56 100644
--- a/sc/source/filter/ftools/fprogressbar.cxx
+++ b/sc/source/filter/ftools/fprogressbar.cxx
@@ -24,7 +24,7 @@
 #include <osl/diagnose.h>
 #include <tools/stream.hxx>
 
-#include <climits>
+#include <limits>
 
 ScfProgressBar::ScfProgressSegment::ScfProgressSegment( std::size_t nSize ) :
     mnSize( nSize ),
@@ -65,7 +65,7 @@ void ScfProgressBar::Init( SfxObjectShell* pDocShell )
     mpParentProgress = nullptr;
     mpParentSegment = mpCurrSegment = nullptr;
     mnTotalSize = mnTotalPos = mnUnitSize = mnNextUnitPos = 0;
-    mnSysProgressScale = 1;     // used to workaround the ULONG_MAX/100 limit
+    mnSysProgressScale = 1;     // used to workaround the SfxProgress sal_uInt32 limit
     mbInProgress = false;
 }
 
@@ -89,10 +89,10 @@ void ScfProgressBar::SetCurrSegment( ScfProgressSegment* pSegment )
     }
     else if( !mxSysProgress && (mnTotalSize > 0) )
     {
-        // System progress has an internal limit of ULONG_MAX/100.
+        // SfxProgress has a limit of sal_uInt32.
         mnSysProgressScale = 1;
-        sal_uLong nSysTotalSize = static_cast< sal_uLong >( mnTotalSize );
-        while( nSysTotalSize >= ULONG_MAX / 100 )
+        std::size_t nSysTotalSize = mnTotalSize;
+        while( nSysTotalSize > std::numeric_limits<sal_uInt32>::max() )
         {
             nSysTotalSize /= 2;
             mnSysProgressScale *= 2;