[Mono-bugs] [Bug 25692] Changed - values being rounded by the runtime?

[bugzilla-daemon@rocky.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by lupus@ximian.com.

http://bugzilla.ximian.com/show_bug.cgi?id=25692

--- shadow/25692	Mon Jun  3 11:11:53 2002
+++ shadow/25692.tmp.16020	Mon Jun  3 12:37:21 2002
@@ -1,14 +1,14 @@
 Bug#: 25692
 Product: Mono/Runtime
 Version: unspecified
 OS: Red Hat 7.2
 OS Details: 
-Status: NEW   
+Status: ASSIGNED   
 Resolution: 
-Severity: 
+Severity: Unknown
 Priority: Normal
 Component: misc
 AssignedTo: mono-bugs@ximian.com                            
 ReportedBy: ndrochak@gol.com               
 QAContact: mono-bugs@ximian.com
 TargetMilestone: ---
@@ -50,6 +50,34 @@
 Every darn time.
 
 Additional Information:
 
 Class lib is pretty straight forward, but it might be there.  However, 
 I'm guessing runtime.
+
+------- Additional Comments From lupus@ximian.com  2002-06-03 12:37 -------
+The actual problem is in the compiler, though it's not against the spec.
+Not all the values that fit into a long can be represented precisely
+in a double, this means that two different longs may end up in the
+same double value representation.
+This happens in the Convert code when long.MinValue or MaxValue are
+compared with the value to convert, but both the min and max values
+are converted to the same double number (with loss of precision) and
+the test for overflow fails. We need to test for it in a different way.
+The underlying problem is also present in the ms runtime as this test
+will show:
+using System;
+class T {
+        static int Main() {                double max = long.MaxValue;
+                double min = long.MaxValue;
+                Console.WriteLine ("max: {0:R}, min: {1:R}", max, min);
+                if (min == max)
+                        return 1;
+                return 0;
+        }
+}
+
+So, to recap: we need to test for the overflow condition in a
+different way to workarund the issue, because we are relying on
+basically undefined behaviour when a long is implicitly converted to a
+doubles (the same happens with an int and a float).
+