Re: Integers-related trap in Lua 5.3

[Roberto Ierusalimschy <roberto@...>]

> On 18/05/16 10:04 AM, Roberto Ierusalimschy wrote:
> >>>>IMO, both Lua parser and tonumber() function should return correct
> >>>>float values in case of integer overflow.
> >>>>This can be done safely as it does not break the main feature of integers:
> >>>>integers will stay integers after tonumber(tostring(x)) conversion cycle.
> >One problem with all proposed solutions is math.mininteger. The
> >lexer reads numbers without signal. (Several languages do the
> >same, e.g. C).  This means that -9223372036854775808 is read as
> >-(9223372036854775808) (a unary minus applied over a positive
> >constant). But 9223372036854775808 is not a valid integer, so it would
> >result in a float (or nil, or inf, or error). Whatever the choice, the
> >final value of -9223372036854775808 would not be an integer, despite
> >it being a valid integer.
> >
> >(If the value results in a float, its negative can still be converted
> >back to an integer with the exact value, so it is not a huge
> >problem. But it is still weird...)
> >
> >-- Roberto
> >
> Parser/lexer shouldn't be a performance priority (load() in
> performance-critical code is stupid), but I can see tonumber() being
> a problem. But then again tonumber() *does* parse negative
> integers...
> 
> If you need max performance when parsing integers you should use
> math.tointeger() IMO.

My point has nothing to do with performance.

-- Roberto