Yes, the reason the larger one works is because the parameters to * just happen to overflow to values that let the result of * not go out of bounds.
As for doing bounds checking during (int), I think that would be a net loss. Generally speaking, casting to a primitive is intended to aid performance, and done prior to arithmetic which might result in an out of bounds number. Bounds checking would hurt the former while being superfluous in the latter; basically it would only protect the case where you start out with a large number, as the example does. Now, I do think bounds checking functions such as int?, long?, would be nice for those cases when a function is accepting a possibly-too- large large number as a parameter and wants to play it safe. On May 29, 12:14 pm, Dex Wood <slash2...@gmail.com> wrote: > The failure to detect the integer overflow is not the fault of the > multiply function itself. The integer argument has already overflown > by the time it reaches the multiply function. Maybe adding overflow > detection to the coercion functions would be a solution? > > On May 29, 1:51 pm, Dex Wood <slash2...@gmail.com> wrote: > > > I was experimenting with math operations and I came across the oddity: > > > user=> (* (int 2) (int 356666666666666666666)) > > -1029352108 > > user=>(* (int 2) (int 3566666666666666666)) > > java.lang.ArithmeticException: integer overflow > > > The top one should throw an integer overflow exception too, but in > > this case it does not. I dived deep into Numbers.java to see how it > > detects an overflow in the multiplication, and I discovered that it > > does two tests. y != 0 and ret/y != x. In the top case: ret: > > -1029352108 x: 2 y: -514676054 > > > The first test passes, because y is not 0 and the second test fails > > because ret/y does indeed equal x: -1029352108/-514676054 = 2. So it > > returns garbage without throwing the exception. In this rare cast, > > the overflowed values divided equal x, which would normally signify > > that the calculation was correct. Perhaps we should come up with a > > better overflow detection condition. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
