[Python-Dev] test_builtin failing? or just 64-bit platforms

Tim Peters tim.one@home.com
Fri, 30 Nov 2001 21:41:56 -0500


[Mark Favas]
> Anyone else getting test_builtin failures with current CVS,

No.

> or does it only show on 64-bit platforms? Changes in the past week
> seem to have caused the failure. Isolated to following (will post bug
> on SF):

Thanks!

> ***** older CVS works *****
> 201 mark@gonzo.per.dem.csiro.au python
> Python 2.2b2+ (#539, Nov 26 2001, 09:52:25) [C] on osf1V4
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import sys
> >>> s=-1-sys.maxint
> >>> d=`s`
> >>> d
> '-9223372036854775808'
> >>> s
> -9223372036854775808
> >>> ^D
>
> ***** current CVS fails *****
> 202 mark@gonzo.per.dem.csiro.au cd dist/src
> 203 mark@gonzo.per.dem.csiro.au ./python
> Python 2.2b2+ (#541, Dec  1 2001, 08:04:58) [C] on osf1V4
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import sys
> >>> s=-1-sys.maxint
> >>> d=`s`
> >>> d
> '8t\x10@\x01'
> >>> s
> -9223372036854775808
> >>> ^D

It doesn't make sense, but it *smells* like a sprintf -> PyOS_snprintf
screwup ... OK, our int repr code has always been wrong(!):

static PyObject *
int_repr(PyIntObject *v)
{
	char buf[20];
	PyOS_snprintf(buf, sizeof(buf), "%ld", v->ob_ival);
	return PyString_FromString(buf);
}

20 bytes isn't enough to hold the result on a 64-bit box (insert rant about
the idiot practice of trying to make stack buffers as small as possible).
You have 20 characters in your result, but need 21 to hold the trailing 0
byte too.  I don't know what snprintf does when there's not enough room, but
I think you just showed us what it does on Tru64 <wink>.

Doing repr impllicitly instead works because that goes thru int_print
instead of int_repr.  Doing repr explicitly "worked" before by accident (the
trailing null overwrite some random byte on the stack).  Please change 20 to
200(*) (or 64 -- your choice) and see whether that fixes it?