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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4