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 -~----------~----~----~----~------~----~------~--~---
