[Patches] printf("%lx") -> printf("%p") for pointers : win64 cares

Trent Mick trentm@activestate.com
Fri, 12 May 2000 23:41:15 -0700


On Sat, May 13, 2000 at 02:21:55AM -0400, Tim Peters wrote:
> [Trent Mick, patches Python to use %p for pointer printing]
> > ...
> > The changes do not only affect Win64 (as one would hope) because the
> > %p formatter on *NIX (on Linux32 and Linux64 at least) seems to
> > prepend '0x' to the hex representation of the pointer. WIn32 and Win64
> > do NOT prepend this.  Go figure.
> 
> 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)!

Do you have a suggestion for a good ANSI/ISO C reference? It might more
efficient for me to read these things than me playing, making patches, and
having you teach me through comments on my patch. :)

> 
> > However, does it matter that the hex output format now includes
> > the '0x' prefix on Linux32?
> 
> Well, gratuitous (from a Linux32 user's POV) change can't be considered a
> good thing.
> 
> > 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 or
will I have to #ifdef in %p usage for Win64 only until the magical C95 (is
that what it will be called? can't remember the number you mentioned) comes
out and solves all our problems. Actually, will the next C standard define
output for a pointer printf formatter.

Thanks,
Trent


-- 
Trent Mick
trentm@activestate.com