2013/3/22 Stephan Bergmann <sberg...@redhat.com> > On 03/22/2013 11:44 AM, Zolnai Tamás wrote: > >> Otherwise in ImplNumericGetValue() the problem of overflow/underflow can >> be avoid with these lines >> sal_Int64 nValue = aStr.toInt64() >> if( OUString::valueOf(nValue) != aStr ) >> { >> if( bNegative ) >> rValue = SAL_MIN_INT64; >> else >> rValue = SAL_MAX_INT64; >> return sal_True; >> } >> > > ...but only if aStr is known to be in canonical form, esp. neither > contains minus zero nor contains excessive leading zero digits. None of > that is guaranteed for ImplNumericGetValue in its current form (and also > consider nDecDigits > 0, where input rStr="0" and nDecDigits=2, say, would > lead to aStr="000" and the above comparison erroneously failing). >
Oh, that's true. Thanks. I extend the check to take notice of these two things. >From that matter, why is that the toInt64() function doesn't pay attention on overflow/underflow? Maybe it would simpler to handle these "flows" in that function. Regards, Tamás
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice