]> git.ipfire.org Git - thirdparty/Python/cpython.git/commit
Fix for SF bug #415514: "%#x" % 0 caused assertion failure/abort.
authorTim Peters <tim.peters@gmail.com>
Thu, 12 Apr 2001 00:35:51 +0000 (00:35 +0000)
committerTim Peters <tim.peters@gmail.com>
Thu, 12 Apr 2001 00:35:51 +0000 (00:35 +0000)
commit711088d9b8c6898aad571fb251cb40a8b7d42f64
tree937822a57e2984b35b9720c9b67fa0f0e0d213f0
parent4642cb9ac9636dec1e939a75f5da3fc263b51326
Fix for SF bug #415514: "%#x" % 0 caused assertion failure/abort.
http://sourceforge.net/tracker/index.php?func=detail&aid=415514&group_id=5470&atid=105470
For short ints, Python defers to the platform C library to figure out what
%#x should do.  The code asserted that the platform C returned a string
beginning with "0x".  However, that's not true when-- and only when --the
*value* being formatted is 0.  Changed the code to live with C's inconsistency
here.  In the meantime, the problem does not arise if you format a long 0 (0L)
instead.  However, that's because the code *we* wrote to do %#x conversions on
longs produces a leading "0x" regardless of value.  That's probably wrong too:
we should drop leading "0x", for consistency with C, when (& only when) formatting
0L.  So I changed the long formatting code to do that too.
Lib/test/test_format.py
Objects/stringobject.c
Objects/unicodeobject.c