<div dir="ltr">Thanks! Committed at r236326.<div><br></div><div><br></div><div>Diego.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 1, 2015 at 12:52 PM, Duncan P. N. Exon Smith <span dir="ltr"><<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On 2015 May 1, at 07:52, Diego Novillo <<a href="mailto:dnovillo@google.com">dnovillo@google.com</a>> wrote:<br>
><br>
><br>
> Duncan,<br>
><br>
> I'm tracking down an infinite recursion problem when calling toInt.  The problem seems to be that in the call to toInt, we call compareTo which, in turn, calls toInt in one of its paths. This does not happens on 64bit Scaled numbers.  I'm trying to work out a fix, but maybe you'll spot the problem quicker.<br>
><br>
> Here's a unittest that triggers the problem. I ran into it with another patch I'm working on that needs to multiply scaled32 numbers that are often 1.<br>
<br>
</span>I was over-thinking this =/.  The attached patch removes the<br>
(accidental) co-recursion by gutting the logic in `compareTo()`.<br>
Feel free to commit with your test, or I can.<br>
<br>
<br><br>
<br>
> In tracing this, I'm thinking that we could probably add some short-circuits to avoid so many calls when dealing with trivial numbers (but that's unrelated).<br>
<br>
<br>
Go ahead and micro-optimize if you think it'll make the code faster<br>
in practice.<br></blockquote></div><br></div>