2013/3/22 Stephan Bergmann <span dir="ltr"><<a href="mailto:sbergman@redhat.com" target="_blank">sbergman@redhat.com</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 03/22/2013 11:44 AM, Zolnai Tamás wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Otherwise in ImplNumericGetValue() the problem of overflow/underflow can<br>
be avoid with these lines<br>
sal_Int64 nValue = aStr.toInt64()<br>
if( OUString::valueOf(nValue) != aStr )<br>
{<br>
     if( bNegative )<br>
         rValue = SAL_MIN_INT64;<br>
     else<br>
         rValue = SAL_MAX_INT64;<br>
     return sal_True;<br>
}<br>
</blockquote>
<br></div>
...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).<br>
</blockquote><div><br></div><div>Oh, that's true. Thanks. I extend the check to take notice of these two things.</div><div>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.</div>
<div><br></div><div><br></div><div>Regards,</div><div>Tamás</div></div><br>