[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
**Subject**: **Re: Negative table index**
**From**: Roberto Ierusalimschy <roberto@...>
**Date**: Mon, 22 Dec 2014 13:13:12 -0200

> table.move forbids a negative index on the source index, but not the
> destination. Why the restriction? And why not restrict both source and
> destination? There's a comment about overflow, but I don't see where it would
> be a problem. Perhaps the statement 'n = e - f + 1' but isn't it possible to
> detect overflow?
Consider the statement:
table.move({}, math.mininteger, math.mininteger+20, math.maxinteger-5)
At first, it would move elements to the right, but after the destination
index wraps around, it would then move elements to the left. Because
source and destination overlap, the move might have to be performed in
two steps, to avoid moved elements overwriting elements still to be
moved. Surely we could do several different checks and avoid all
problems, but this trivial (and, in our view, harmless) test seems
simpler to explain, understand, and implement.
> And why not check for overflow on the destination too?
>
> > table.move({"a","b","c"},1,3, math.maxinteger*2+1,{})
> > table.move(t,1,math.maxinteger*2+1, -1,{})
The expression 'math.maxinteger*2+1' evaluates to -1 (by the rules
of arithmetic overflows) before the function is called. The calls
then become
table.move({"a","b","c"},1,3, -1,{})
table.move(t,1,-1, -1,{})
-- Roberto