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

noreply@sourceforge.net noreply@sourceforge.net
Thu, 12 Apr 2001 11:41:03 -0700


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-12 11:41

Message:
Logged In: YES 
user_id=31435

Changed the fix:  Python now produces a base marker (for %
#x and %#X conversion) whether or not the value is 0, and 
whether or not 0 is short or long.  This is inconsistent 
with C, but is consistent with Python's hex(), consistent 
with what Python did before for conversion of 0L, and more 
predictable in any case.  Since conversion of short 0 blew 
up before, Python didn't follow C's behavior before either.

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

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