cc-tweaked / Cobalt

A re-entrant fork of LuaJ
Other
72 stars 13 forks source link

PUC compatiblity: Formatting NaN with "%d" returns 0 #54

Closed sir-maniac closed 1 year ago

sir-maniac commented 3 years ago

A compatibility edge case was discovered during discussion here, so adding this issue for reference.

SquidDev commented: For reference:

$ lua5.1
Lua 5.1.5  Copyright (C) 1994-2012 Lua.org, PUC-Rio
> =("%d"):format(0/0)
-9223372036854775808

$ lua5.3
Lua 5.3.6  Copyright (C) 1994-2020 Lua.org, PUC-Rio
> =("%d"):format(0/0)
stdin:1: bad argument #1 to 'format' (number has no integer representation)

Meanwhile Cobalt returns 0.

I think the best way to handle this is to modify StringFormat, as I think LuaValue.checkLong should return the value it currently returns. So a check if the value is double, and if so, either call Double.doubleToLongBits (lua 5.1), or signal an error (lua 5.3).

https://github.com/SquidDev/Cobalt/blob/2cec621e10982ed98024952daa138ce13ad718d9/src/main/java/org/squiddev/cobalt/lib/StringFormat.java#L79-L86

sir-maniac commented 3 years ago

Another interesting issue with PUC lua5.1(linux):

> =string.format("%d", 0/0)
-9223372036854775808
> =("%d").format(0/0)
-nan
Kan18 commented 3 years ago

Another possibly-related issue:

print(-0.0)

prints -0 on versions of PUC Lua before 5.3, -0.0 on versions of PUC Lua after/including 5.3, but 0 on Cobalt

Kan18 commented 2 years ago

Another interesting issue with PUC lua5.1(linux):

> =string.format("%d", 0/0)
-9223372036854775808
> =("%d").format(0/0)
-nan

shouldn't the ("%d").format be ("%d"):format here?