Related: tdf#130725: use strtod also in rtl::math::stringToDouble

Size of buffer on stack is 256 characters. Logging function usage
in make check, of >1 100 000 invocations, the longest string was
80 characters, average being 4.6 characters. So heap allocation
is unlikely in scenarios with intensive function usage.

Several existing unit tests had to be fixed. Usually, the change
is either minimal or getting closer to what Excel returns (for
Calc tests). But in case of AMORDEGRC, I had to change rate value
passed to the function from 0.3 to 0.31. It's because the closest
double value for 0.3 is 0.29999999999999999, which is a bit less
than 0.3; multiplied by 1.5, this gives 0.44999999999999996, and
then rounding the result of multiplication of the latter by cost
gave the result 1 less than before, when 0.3 was imported as
0.30000000000000004. Now the function returns a value 1 less than
Excel for that set of arguments. I don't see how to fix that.
Having rate slightly different gives consistent result between
Calc and Excel.

Change-Id: Icae5ce374fe0c31a1aa10cee815e65ef0014f382
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89422
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>

1 files changed, 1 insertions, 0 deletions

diff --git a/sal/Library_sal.mk b/sal/Library_sal.mk
index e84ed0aaf1b5..42e3dc53e301 100644
--- a/sal/Library_sal.mk
+++ b/sal/Library_sal.mk
@@ -39,6 +39,7 @@ $(eval $(call gb_Library_use_libraries,sal,\
 ))
 
 $(eval $(call gb_Library_use_externals,sal,\
+    dtoa \
     valgrind \
 ))