From: Thomas Wouters <thomas@python.org>
Date: Wed, 23 May 2001 12:30:59 +0000 (+0000)
Subject: Backport Tim's checkin 2.104:
X-Git-Tag: v2.1.1c1~117
X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=4a11bb3f86a5d5ca975f800cf1740b9253794ab7;p=thirdparty%2FPython%2Fcpython.git

Backport Tim's checkin 2.104:

A different approach to the problem reported in
Patch #419651: Metrowerks on Mac adds 0x itself
C std says %#x and %#X conversion of 0 do not add the 0x/0X base marker.
Metrowerks apparently does.  Mark Favas reported the same bug under a
Compaq compiler on Tru64 Unix, but no other libc broken in this respect
is known (known to be OK under MSVC and gcc).
So just try the damn thing at runtime and see what the platform does.
Note that we've always had bugs here, but never knew it before because
a relevant test case didn't exist before 2.1.
---

diff --git a/Objects/stringobject.c b/Objects/stringobject.c
index 1701b2fcc39a..a3cc7826feaa 100644
--- a/Objects/stringobject.c
+++ b/Objects/stringobject.c
@@ -2673,9 +2673,13 @@ formatint(char *buf, size_t buflen, int flags,
 	/* When converting 0 under %#x or %#X, C leaves off the base marker,
 	 * but we want it (for consistency with other %#x conversions, and
 	 * for consistency with Python's hex() function).
+	 * BUG 28-Apr-2001 tim:  At least two platform Cs (Metrowerks &
+	 * Compaq Tru64) violate the std by converting 0 w/ leading 0x anyway.
+	 * So add it only if the platform didn't already.
 	 */
-	if (x == 0 && (flags & F_ALT) && (type == 'x' || type == 'X')) {
-		assert(buf[1] != type);  /* else this C *is* adding 0x/0X */
+	if (x == 0 && (flags & F_ALT) && (type == 'x' || type == 'X') &&
+	    buf[1] != (char)type) /* this last always true under std C */
+		{
 		memmove(buf+2, buf, strlen(buf) + 1);
 		buf[0] = '0';
 		buf[1] = (char)type;