printf("%lx") -> printf("%p") for pointers : win64 cares about cpython HOT 5 CLOSED

from cpython.

Checked in verbatim.

from cpython.

Accepted & passed back to Trent. We *have* to check this one in, so David Ascher can eliminate all the tedious semaphore debug code you so tediously repaired <wink>.

from cpython.

I confirm that, to the best of my knowledge and belief, this
contribution is free of any claims of third parties under
copyright, patent or other rights or interests ("claims"). To
the extent that I have any such claims, I hereby grant to CNRI a
nonexclusive, irrevocable, royalty-free, worldwide license to
reproduce, distribute, perform and/or display publicly, prepare
derivative versions, and otherwise use this contribution as part
of the Python software and its related documentation, or any
derivative versions thereof, at no cost to CNRI or its licensed
users, and to authorize others to do so.

I acknowledge that CNRI may, at its sole discretion, decide
whether or not to incorporate this contribution in the Python
software and its related documentation. I further grant CNRI
permission to use my name and other identifying information
provided to CNRI by me for use in connection with the Python
software and its related documentation.

from cpython.

This is a revival submission. This got discussed (at least by Tim and I) and
then it died.

Background:

The common technique for printing out a pointer has been to cast to a long
and use the "%lx" printf modifier. This is incorrect on Win64 where casting
to a long truncates the pointer. The "%p" formatter should be used instead.

before (with a debugging printf of my own):

>>> class spam: pass
...
>>> repr(spam)
real pointer value is 000003FFFFC58340   # my own printf in the class_repr fn
'<class __main__.spam at ffc58340>'
>>>

after:

>>> class spam: pass
...
>>> repr(spam)
'<class __main__.spam at 000003FFFFC58340>'
>>>

The problem as stated by Tim:

Unfortunately, the C committee refused to define what %p conversion "looks
like" -- they explicitly allowed it to be implementation-defined. Older
versions of Microsoft C even stuck a colon in the middle of the address (in
the days of segment+offset addressing)!

The result is that the hex value of a pointer will maybe/maybe not have a 0x
prepended to it.

[Tim answers some question of mine about this problem]

> I.e. does Python promise the repr output to look EXACTLY the way it does?

No.

> Will reasonable code out there break?

Probably, but not much. I'm sure much more code will break due to 1.6
dropping the trailing "L" on str(long), for example.

> ...
> Given that %p is "implementation defined" do you see this patch
> going in

I'd put it in, if I were Guido.

From here is Guido's call, I guess. So here is the patch (again).

Notes on the patch:

There are two main classes of changes:

• in the various repr() functions that print out pointers
• debugging printf's in the various thread_*.h files (these are why the
  patch is large)

from cpython.