Re: Re: [farm-report] Daily Snake Farm report

>  >This is trying to ascertain that the list allocation code does its
>  >range checking right, and in fact, on a 32 bit system, this should
>  >never even call malloc.
> 
> Ah... there was a brief chatter on this a while back, but
> it went nowhere. Probably wrong forum.  I'm behind on my
> python-dev readings.

I've checked in a change to rangeobject.c, which had a clear and
present bug in range_length().  But I think this won't change the test
blowup, since before it would return a negative int, which is treated
the same as what it does now (raising an exception).  In both cases,
list_fill() keeps allocating more memory for the list until it runs
out.

> ...
>  >I'll see if I can fix range_length().  Because PySequence_Size() is
>  >defined as an int (for better or for workse), range_length() has to
>  >return an error if the length is out of range for ints.  Then the
>  >test will do something different (it won't test what it's supposed to
>  >test) on 64-bit platforms; maybe we should not try this test on 64-bit
>  >platforms, or replace sys.maxint/4 by 0x1fffffff.
> 
> Something like that smells reasonable - (64-bit int)/4
> seemed to have potential for trouble in any case.

But then on a 64-bit system the test won't test what it is supposed to
test.  It's supposed to test that the NRESIZE() macro correctly
determines that maxint/4 is more than what you can pass to malloc(),
but that's not the case on a 64 bit platform.  I think the proper fix
to the test is to only run that particular test when
sys.maxint==0x7fffffff.

> By the way, what *should* sys.maxint return on an LP64 platform?
> The "native" view of an "int" continues to 4-byte, but a Python
> int smells more like "the largest integer" (including longs).

A Python int uses a platform long, so sys.maxint should be C's
LONG_MAX.

--Guido van Rossum (home page: http://www.python.org/~guido/)