This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: printf("%lx") -> printf("%p") for pointers : win64 cares
Type: Stage:
Components: None Versions:
process
Status: closed Resolution:
Dependencies: Superseder:
Assigned To: fdrake Nosy List: fdrake, tim.peters, tmick
Priority: normal Keywords: patch

Created on 2000-06-07 02:30 by tmick, last changed 2022-04-10 16:02 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
None tmick, 2000-06-07 02:30 None
Messages (5)
msg32684 - (view) Author: Trent Mick (tmick) (Python triager) Date: 2000-06-07 02:30
 
msg32685 - (view) Author: Fred Drake (fdrake) (Python committer) Date: 2000-06-30 15:03
Checked in verbatim.
msg32686 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2000-06-30 00:29
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>.
msg32687 - (view) Author: Trent Mick (tmick) (Python triager) Date: 2000-06-07 02:30
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.
msg32688 - (view) Author: Trent Mick (tmick) (Python triager) Date: 2000-06-07 02:32
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)
History
Date User Action Args
2022-04-10 16:02:00adminsetgithub: 32428
2000-06-07 02:30:06tmickcreate