[Python-Dev] 2.1c1: test_format failing?

Mark Favas m.favas@per.dem.csiro.au
Fri, 13 Apr 2001 11:43:29 +0800


Responses interpolated below...

[Tim Peters]
> 
> [Mark Favas]
> > I've tried the test program on a few of my Tru64 boxes (with different
> > versions of the OS and different versions of the compiler) and all
> > print "00".
> 
> Then that's why Python '%#o' % 0 also returns "00" (formats of short ints use
> the platform sprintf).  As far as I'm concerned, then, this is a
> long-standing bug in Compaq's C (the blurb I quoted before was verbatim from
> the C standard, and addressed this specific case).
> 
> I expect you'll find that '%#o' % 0L returns "0" even on your box, because
> Python does its own formats on long ints.

It does indeed.


> 
> As time goes on, and we eradicate the differences between ints and longs, I
> expect we'll end up using the Python long int format code all the time.
> 
> Before then, I'm disinclined to add more code to the short int case trying to
> worm around platform C bugs, unless at least one other platform is found
> where
> 
> #include <stdio.h>
> void main() {
>     printf("%#o\n", 0);
> }
> 
> prints 00.

I've just tried Solaris 2.5.1, Solaris 8, FreeBSD 4.2 and even(!) Irix
6.5 - all produce "0" - :( or :) depending on your POV.


> 
> BTW, what does this print for you (just changing "o" to "x")?
> 
> #include <stdio.h>
> void main() {
>     printf("%#x\n", 0);
> }
> 
> If they print 0x0 for that (they're supposed to print 0), current CVS Python
> will assert-fail in debug mode on '%#x' % 0.

This produces "0"

-- 
Mark Favas  -   m.favas@per.dem.csiro.au
CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA