Metrowerks on Mac adds 0x itself

[jackjansen]

BPO	419651
Nosy	@tim-one, @jackjansen
Files	unicodeobject.patch

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields: ```python assignee = 'https://github.com/tim-one' closed_at = created_at = labels = ['interpreter-core'] title = 'Metrowerks on Mac adds 0x itself' updated_at = user = 'https://github.com/jackjansen' ``` bugs.python.org fields: ```python activity = actor = 'tim.peters' assignee = 'tim.peters' closed = True closed_date = None closer = None components = ['Interpreter Core'] creation = creator = 'jackjansen' dependencies = [] files = ['3298'] hgrepos = [] issue_num = 419651 keywords = ['patch'] message_count = 6.0 messages = ['36480', '36481', '36482', '36483', '36484', '36485'] nosy_count = 2.0 nosy_names = ['tim.peters', 'jackjansen'] pr_nums = [] priority = 'normal' resolution = 'fixed' stage = None status = 'closed' superseder = None type = None url = 'https://bugs.python.org/issue419651' versions = [] ```

[jackjansen]

The Metrowerks C library on the Mac already prints 0 as 0x0 so don't add another 0x to the front of that.

[tim-one]

Logged In: YES user_id=31435

Jack, there's no patch here.

Have you reported this bug to Metrowerks? The C std is very clear that a %#x format must *not* produce a leading 0x when and only when the number being converted is 0.
This isn't a debatable issue: if they're producing 0x0, they're wrong.

[jackjansen]

Logged In: YES user_id=45365

[jackjansen]

Logged In: YES user_id=45365

There's a patch now. Silly form wanted me to check the box, even though I had used the attach button:-(

I'll also send the bug report to metrowerks, but that'll be a looooong time in fixing, I guess. Do you (or anyone else) happen to have a section number/etc for the requirement?

[tim-one]

Logged In: YES user_id=31435

Section 7.9.6.1 ("The fprintf function"), under the description of the "#" flag character: "For x (or X) conversion, a nonzero result will have Ox (or 0X) prefixed to it."

In the meantime, at least one other box is known that screws this up, and I said at the time that if a second box ever appeared, I'd do something about it \<wink>.

[tim-one]

Logged In: YES user_id=31435

An ifdef on the compiler isn't the right way to worm around this: it's not unique to this box, and since it's a bug on the box it *should* get fixed someday (at which point the ifdef'ed code will do a wrong thing for the box).

Checked in another approach without ifdefs. Please test on your box and scream if it still fails.

Objects/stringobject.c; new revision: 2.104 Objects/unicodeobject.c; new revision: 2.88