Issue400505
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.
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) | Date: 2000-06-07 02:30 | |
|
|||
msg32685 - (view) | Author: Fred Drake (fdrake) | Date: 2000-06-30 15:03 | |
Checked in verbatim. |
|||
msg32686 - (view) | Author: Tim Peters (tim.peters) * | 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) | 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) | 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:00 | admin | set | github: 32428 |
2000-06-07 02:30:06 | tmick | create |