[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Negative table index
- From: Tom N Harris <telliamed@...>
- Date: Tue, 23 Dec 2014 23:36:20 -0500
On Tuesday, December 23, 2014 05:27:23 PM Roberto Ierusalimschy wrote:
> 'INT_MAX - t' will overflow for any negative 't' and therefore invalidate
> the check. I am out now.
>
I did warn you that I have difficulty with signed overflow.
The question I had was if there was a problem other than wrapping of the
destination. The answer is "yes". 'n = e - f + 1' can overflow with f<=0.
That's why checking just the destination isn't enough.
One of the things I was missing that I see now is Lua integer arithmetic is
done over unsigned integers so there's no undefined overflow. That's why
't[math.maxinteger+1] = "x"' will work. (And internally, tables store all
integers as unsigned.) But you can still run into trouble when using library
functions that add lua_Integer. 'table.move(t,1,2,math.maxinteger)' is
undefined. Would it be helpful to calculate 'n' as unsigned? Would it be much
slower or complex? I also need to refresh my memory about mixed-sign
arithmetic. (I think it promotes to unsigned.) table.unpack uses Unsigned.
tinsert:
lua_Integer e = aux_getn(L, 1, &ta) + 1;
Is there a condition somewhere else that prevents this from overflowing? Other
than the machine would have run out of memory first. Looks like the only check
is MAXASIZE which is 1u<<number_of_bits_in_int.
I think it's unfortunate that not allowing negative indexes prevents uses that
wouldn't cause overflow. But we're living in the gray area of table arrays
that aren't strictly defined sequences. This is also something I shouldn't
have waited for the RC versions to think about.
--
tom <telliamed@whoopdedo.org>