Re: problem with string.format %d and very large integers

[Norman Ramsey <nr@...>]

 > > 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

That's really unfortunate.  I liked the story about 'all numbers are
IEEE doubles', but it sounds like the real story is 'all numbers are
IEEE doubles, except when they are cast to C ints.'   That's not
nearly as good.

 > 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.

If the problem is widespread, I wouldn't argue that 'format' should
get special privileges.   With table indices, you did such a beautiful
job providing "general semantics with good performance for ints" that
I though this might be your goal everywhere.

Is there any chance that the new manual for 5.2 can list explicitly
every place that a Lua number is coerced to a C int?  So far I know
about certain arguments to string.format and about string indices.  
I assume that general table indices are *not* converted to ints.  
But it would be good to have the information written down...

What are your thoughts about using int64?  Not ANSI?  Not performant?


Norman