diff options
| author | Tim Peters <tim.peters@gmail.com> | 2001-04-12 00:35:51 (GMT) |
|---|---|---|
| committer | Tim Peters <tim.peters@gmail.com> | 2001-04-12 00:35:51 (GMT) |
| commit | 711088d9b8c6898aad571fb251cb40a8b7d42f64 (patch) | |
| tree | 937822a57e2984b35b9720c9b67fa0f0e0d213f0 /Misc | |
| parent | 4642cb9ac9636dec1e939a75f5da3fc263b51326 (diff) | |
| download | cpython-711088d9b8c6898aad571fb251cb40a8b7d42f64.zip cpython-711088d9b8c6898aad571fb251cb40a8b7d42f64.tar.gz cpython-711088d9b8c6898aad571fb251cb40a8b7d42f64.tar.bz2 | |
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.
Diffstat (limited to 'Misc')
0 files changed, 0 insertions, 0 deletions