Re: NumericBox unsafe double conversion

Hi Kendy,

2013/3/20 Jan Holesovsky <kendy@suse.cz>

> Hi Tamás,
>
> Zolnai Tamás píše v Po 18. 03. 2013 v 17:56 +0100:
>
>
> > And the problem was found in this function, in line 199:
> > double nValue = rtl::OUString(aStr).toDouble();
> >
> >
> > In general the NumericBox store its data in an sal_Int64 variable, but
> > here this OUString->double conversion cause changes in big numbers.
> > The "aStr" variable comes from GetText() function, which gives the
> > NumericBox's content, so it is a string representation of an sal_Int64
> > value. I don't know this behaviour is the expected from the
> > OUString::toDouble() function, or it is a bug.
>
> Terribly sorry for my late answer.  I read the code there, and I'd just
> kill the double from the code that is there (ie. from all the methods
> that call ImplNumericGetValue() etc.), and instead of
> OUString::toDouble() used OUString::toInt64().
>
> The logic of ImplNumericGetValue() is that it splits the number to part
> in front of the decimal point/comma, and after that, creates one
> sal_Int64 number from that, and converts that to double.  Nevertheless,
> later it is converted back to sal_Int64.  If the conversion to double
> was there to avoid some overflows, the value will overflow anyway as
> soon as you try to convert it back; but of course, you should be careful
> when doing your changes, mostly in the area of conversions that include
> multiplication.

Yes, I give it a try. I think the mentioned multiplication is
in MetricField::ConvertDoubleValue(), which not need to change, as I see.
I think three function would be changed:
ImplNumericGetValue(), ImplMetricGetValue(), ImplCurrencyGetValue()
The out parameter of these funcitons would be sal_Int64 instead of double.
In ImplMetricGetValue() usage of MetricField::ConvertDoubleValue() would be
changed only with little things.
Call it with (double)rValue as its first parameter and cast its return
value to sal_Int64.
So I make it in this way, and will see wheather it solves the problem.

Best regards,
Tamás