 |
lua-l archive |
|
|
||
|
On 29/07/2011 20.18, Roberto Ierusalimschy wrote:
BTW I wonder if this issue is going to be fixed in some way in 5.2.0. Lua team hasn't commented on the subject so I wonder whether it is considered a bug to be squashed in the official distro, or it is to be viewed simply as a "platform idiosyncrasy" to be coped with downstream.We added a note in the manual about the limits of integer formats, but I am not sure we will do anything else. There are many places where the same problem occurs (basically everywhere that C code uses an int): > return string.sub("Hello", 2^32 + 2, 2^32 + 3) el > print(unpack({1,2,3}, 1, 2^32 + 2)) 1 2 The ".0f" trick works neither for "%d" with a precision nor for "%x" and "%o". Tests everywhere will add size, complexity, and slow down the interpreter. We need to compromise somewhere. We may add an explicit test only for 'format', but I am not sure why it deserves a protection more than the other functions. -- Roberto
Thank you for the reply! I wasn't aware that the problem was so ubiquitous.So, if I'm getting it right, we may rely on "integers" only if they are representable on 32 bit (which is the minimum width of an int guaranteed by the C standard, IIRC). An this even when lua is compiled with double as lua_Number, which could represent exactly integers with 52 (?) bit.
So the problem becomes to know what facilities in Lua implicitly use an int. Well, it's easy to imagine that string positions can be considered C ints. From the examples above it seems that also table integer indexes should be considered C ints in some contexts. This poses some problems: if it is ok to limit unpack integer args to 32 bit (an array with more than 2^31 elements is unlikely - if ever possible with current memory sizes), one could wonder whether we can rely on this:
t = {}
t[1] = "AARGGH!"
t[2^32+1] = "hello!"
print( t[2^32+1] ) --> hello! (but could it ever be AARGGH!! ?)
I assume we can relay on that case, but is it feasible to put in the
manual a comprehensive list of where this "implicit 32 bit integer"
problem could bite us?
Cheers. -- Lorenzo