[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