From 4a11bb3f86a5d5ca975f800cf1740b9253794ab7 Mon Sep 17 00:00:00 2001 From: Thomas Wouters Date: Wed, 23 May 2001 12:30:59 +0000 Subject: 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. --- Objects/stringobject.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/Objects/stringobject.c b/Objects/stringobject.c index 1701b2f..a3cc782 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; -- cgit v0.12