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

[Libreoffice Gerrit user]

 sc/source/core/tool/interpr3.cxx |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

New commits:
commit e8cb36fd6234270c8c31147db35cccab9c234529
Author:     Eike Rathke <erack at redhat.com>
AuthorDate: Mon Aug 27 10:09:32 2018 +0200
Commit:     Eike Rathke <erack at redhat.com>
CommitDate: Mon Aug 27 14:49:14 2018 +0200

    Increase arbitrary sort elements limit from 100000 to two full columns
    
    The value 100000 already was in the year 2000 initial commit,
    probably some memory and performance constraints back then. At
    least one full column should be sortable, make it two so we don't
    bail out that early for functions like MODE() that can take
    multiple ranges. In fact maybe ScMatrix::IsSizeAllocatable()
    should be taken into account, which is much larger though and
    QuickSort() might not play well with it.
    
    Change-Id: I061abfd0f061c8df62c31468df744eb5dc7152be
    Reviewed-on: https://gerrit.libreoffice.org/59637
    Reviewed-by: Eike Rathke <erack at redhat.com>
    Tested-by: Eike Rathke <erack at redhat.com>

diff --git a/sc/source/core/tool/interpr3.cxx b/sc/source/core/tool/interpr3.cxx
index 7c46264f83e0..e1d7bf45db8e 100644
--- a/sc/source/core/tool/interpr3.cxx
+++ b/sc/source/core/tool/interpr3.cxx
@@ -39,7 +39,9 @@
 using ::std::vector;
 using namespace formula;
 
-#define MAX_COUNT_DOUBLE_FOR_SORT 100000
+/// Two columns of data should be sortable with GetSortArray() and QuickSort()
+// This is an arbitrary limit.
+#define MAX_COUNT_DOUBLE_FOR_SORT (MAXROWCOUNT * 2)
 
 const double ScInterpreter::fMaxGammaArgument = 171.624376956302;  // found experimental
 const double fMachEps = ::std::numeric_limits<double>::epsilon();