From: Alex Martelli Date: Wed, 22 Aug 2007 21:14:17 +0000 (+0000) Subject: Fix compile.c so that it records 0.0 and -0.0 as separate constants in a code X-Git-Tag: v2.6a1~1464 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=d8672aa8a4c925c69cac51561c68a9820cf97124;p=python Fix compile.c so that it records 0.0 and -0.0 as separate constants in a code object's co_consts tuple; add a test to show that the previous behavior (where these two constants were "collapsed" into one) causes serious malfunctioning. --- diff --git a/Lib/test/test_float.py b/Lib/test/test_float.py index fb47db8eb0..1c74c96d3c 100644 --- a/Lib/test/test_float.py +++ b/Lib/test/test_float.py @@ -81,6 +81,7 @@ class UnknownFormatTestCase(unittest.TestCase): # on an IEEE platform, all we guarantee is that bit patterns # representing infinities or NaNs do not raise an exception; all else # is accident (today). +# let's also try to guarantee that -0.0 and 0.0 don't get confused. class IEEEFormatTestCase(unittest.TestCase): if float.__getformat__("double").startswith("IEEE"): @@ -99,6 +100,20 @@ class IEEEFormatTestCase(unittest.TestCase): ('ob_type); + /* _and_ to distinguish 0.0 from -0.0 e.g. on IEEE platforms */ + if (PyFloat_Check(o)) { + double d = PyFloat_AS_DOUBLE(o); + unsigned char* p = (unsigned char*) &d; + /* all we need is to make the tuple different in either the 0.0 + * or -0.0 case from all others, just to avoid the "coercion". + */ + if (*p==0 && p[sizeof(double)-1]==0) + t = PyTuple_Pack(3, o, o->ob_type, Py_None); + else + t = PyTuple_Pack(2, o, o->ob_type); + } else { + t = PyTuple_Pack(2, o, o->ob_type); + } if (t == NULL) return -1;