Neal Norwitz <neal@metaslash.com> writes:

On Tue, Nov 05, 2002 at 10:38:18PM +0100, Anders Qvist wrote:

...

Between 1036491804 and 1036522446 (should be GMT 2002-11-05, 10:20 and 2002-11-05, 18:54 respectively), test_slice started failing with the following message:

test test_slice failed -- [9, 7, 5, 3, 1] == [0]

om moghedien; linux/alpha. There has been some changes containing pointer arithmetic around line 160 of sliceobjects.c, which might be guilty (just a shot in the dark; 64-bit clean?):

Oops! This is my fault.

It is a 64-bit problem, but doesn't have to do with the checkin to sliceobject. The new test (below) broke with old code too.

vereq(range(10)[::sys.maxint - 1], [0])

The problem is that sizeof(int) != sizeof(long). The parameters for PySlice_GetIndices() and PySlice_GetIndicesEx() take ints, not longs. So the code is doing:

range(10)[::-2]

since the high 32 bits are lost.

The only solution I can think of is to have 2 interfaces: - the old API which takes int/int*, PySlice_GetIndices() deprecate this API and raise overflow exception if (int)value != (long)value - the new API which takes long/long*, PySlice_GetIndicesEx()

PySlice_GetIndicesEx() was added in 2.3.

So you suggest changing PySlice_GetIndicesEx(), right?

Otherwise, we are stuck with slices only being able to support 32 bits even on 64 bit architectures.

Other ideas?

I think the better idea is to call _PyEval_SliceIndex for the step element of the slice too. And maybe change the latter from else if (x < -INT_MAX) x = 0; to else if (x < -INT_MAX) x = -INT_MAX; Can you test this on a 64 bit platform or shall I just check it in? Cheers, M. -- After a heavy night I travelled on, my face toward home - the comma being by no means guaranteed. -- paraphrased from cam.misc