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?):
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.
Otherwise, we are stuck with slices only being able to support
32 bits even on 64 bit architectures.
Other ideas?
Neal
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