[Python-bugs-list] [ python-Bugs-415514 ] "%#x" % 0 caused assertion failure/abort

[noreply@sourceforge.net]

Bugs item #415514, was updated on 2001-04-11 13:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=415514&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
Priority: 7
Submitted By: Fergal Mc Carthy (rahn_tamalin)
Assigned to: Tim Peters (tim_one)
>Summary: "%#x" % 0 caused assertion failure/abort

Initial Comment:
[I am unable to fix a similar problem report, even
 searching for the assertion failure. Please forgive
 me if I'm reporting a known problem.]

With python 2.0, I've found that if I tried to print a 
value of 0 with a % format of "%#x" that this 
generates the following aborts under both Unix (Tru64) 
and Windows (98SE).

"%#o" doesn't have problems.

[python 2.0 built for Digital UNIX (DEC OSF) V4.0d]
Python 2.0 (#1, Apr 11 2001, 20:48:08) [C] on osf1V4
Type "copyright", "credits" or "license" for more 
information.
>>> "%#x" % 0
Assertion failed: pbuf[1] == c, file stringobject.c, 
line 2981

[python 2.0 built for Tru64 UNIX (DEC OSF) V5.0]
Python 2.0 (#1, Apr 11 2001, 20:35:33) [C] on osf1V5
Type "copyright", "credits" or "license" for more 
information.
>>> "%#x" % 0
Assertion failed: pbuf[1] == c, file stringobject.c, 
line 2981

[python 2.0 built for Tru64 UNIX (DEC OSF) V5.1]
Python 2.0 (#2, Apr  8 2001, 20:54:56) [C] on osf1V5
Type "copyright", "credits" or "license" for more 
information.
>>> "%#x" % 0
Assertion failed: pbuf[1] == c, file stringobject.c, 
line 2981


[Windows 98 SE Illegal Operation Exception Details]
PYTHON caused an invalid page fault in
module PYTHON20.DLL at 0167:1e15a784.
Registers:
EAX=ffffffff CS=0167 EIP=1e15a784 EFLGS=00010207
EBX=00000000 SS=016f ESP=0063fb98 EBP=00000078
ECX=3ffffefe DS=016f ESI=0063fffe FS=4b17
EDX=00790f87 ES=016f EDI=0079138b GS=0000
Bytes at CS:EIP:
f3 a5 8b c8 83 e1 03 f3 a4 8b 44 24 18 8b 74 24 
Stack dump:
00761b6c 007747fc 00761b6c 00790ad0 00000000 0063fbfa 
ffffffff 00000064 00790f87 00790f70 ffffffff 00790ae7 
00000008 ffffffff ffffffff 00000000 

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-04-11 17:38

Message:
Logged In: YES 
user_id=31435

Fixed and closed.

Lib/test/test_format.py; new revision: 1.10
Objects/stringobject.c; new revision: 2.101
Objects/unicodeobject.c; new revision: 2.81

>From the checkin msg:

"""
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.
"""

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-11 15:21

Message:
Logged In: YES 
user_id=31435

Assigned to me and boosted the priority.  Dies with the 
same assertion under a debug-build Windows Python.  Since I 
almost certainly added the assert(), I must have been 
suspicious at one time <wink/sigh>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=415514&group_id=5470