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 1701b2fcc39abaebb82704b69ca379b0a5a9ea2b..a3cc7826feaafa8104be8dbc2a90dc1929842df1 100644 (file)
--- 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;