| Summary: | <dev-lang/lua-5.3.0: incorrect string.format output on hppa, riscv, sparc32, ... | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Rolf Eike Beer <eike> |
| Component: | Current packages | Assignee: | William Hubbs <williamh> |
| Status: | RESOLVED CANTFIX | ||
| Severity: | minor | CC: | hppa, jstein, mva, riscv, robbat2, williamh |
| Priority: | Normal | Keywords: | TESTFAILURE |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://github.com/numpy/numpy/issues/8325#issuecomment-290481522 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 783405 | ||
| Attachments: | build.log | ||
|
Description
Rolf Eike Beer
2021-01-31 10:49:34 UTC
1) looks like this only affects tests.
If you just need a package to be installed, you can disable USE=test and build will pass (although, 5.2 is deprecated already).
2) The line it mentions contain
> assert(not pcall(string.format, "%d", 2^63))
i.e. it asserts that 2^63 would be out of range for (decimal) integer, so `string.format()` would throw an error, and so `pcall()` would return `false` (so, after `not()` it will became `true`.
So, as for me, it smells like endianness (big vs little) issue.
I hit this during testing for bug 766528, otherwise I don't care for it. Maybe it does not know that hppa is big endian? Other big endian arches were successfully stabilized already, so it should be fine I think. Any news on stabilizing? I guess, this should be, despite of this failing test, fine, as all other lua versions are stable. ping @marecki,@williamh: Could we still stabilize lua5.2, as rest of all slotted versions are stabilized. Sorry, this fell of my list. This is the only test failure I have seen with this version, so if you think this is worth being stabilized then just do it. Interestingly enough, this is exactly the same test failure I saw while trying to keyword lua-5.2 on riscv. Not an endianness problem then, I guess... Interesting that it's only these two, rather different, arches that fail this test. OK, having tried running 'print(string.format, "%d", 2^63)' under different Lua versions things look rather interesting. For reference, 2 to the 63rd power is 9223372036854775808.
On amd64:
- 5.1 - prints -9223372036854775808, i.e. right absolute value but wrong sign
- 5.2, 5.3, 5.4 - "bad argument" error
On riscv:
- 5.1, 5.2 - prints 9223372036854775807, i.e. is off by one
- 5.3, 5.4 - "bad argument" error
Furthermore, it seems that in spite of the above the whole "integers out of range" section of strings.lua tests appears to be gone from the 5.3 test suite (haven't checked 5.4).
Finally, seeing as string.format in Lua calls sprintf() under the bonnet I've also looked at the output of the C function call 'printf("%ld", 1L << 63);'. On both arches the result is -9223372036854775808.
(In reply to Marek Szuba from comment #8) > OK, having tried running 'print(string.format, "%d", 2^63)' under different > Lua versions things look rather interesting. For reference, 2 to the 63rd > power is 9223372036854775808. But only for unsigned. You are doing signed math, so you actually have only 63 bits, i.e. sign is negative and all other bits are 0 -> INT64_MIN, not UINT64_MAX. So the versions that print a negative value are right. (In reply to Rolf Eike Beer from comment #9) > You are doing signed math, so you actually have only > 63 bits, i.e. sign is negative and all other bits are 0 -> INT64_MIN, not > UINT64_MAX. Oh right, I forgot about the two's complement thing. Still, the output on riscv is clearly wrong... At least it seems the problem is just with printing, as having just converted 2^63 into LE binary using Lua 5.1 I get 0000000000000000000000000000000000000000000000000000000000000001 on both amd64 and riscv. Can you send me a test script or command so I can test on hppa? For printing the numbers I copied the line from the tests and replaced assert() with print() i.e. 'print(pcall(string.format, "%d", 2^63))' (the line in Comment #8 has been pasted wrong, sorry). For conversion to binary, I've used the function from https://stackoverflow.com/questions/9079853/lua-print-integer-as-a-binary . HPPA: echo 'print(pcall(string.format, "%d", 2^63))' | lua5.1 true 2147483647 echo 'print(pcall(string.format, "%d", 2^63))' | lua5.2 true 9223372036854775807 echo 'print(pcall(string.format, "%d", 2^63))' | lua5.3 false bad argument #2 to 'string.format' (number has no integer representation) Sparc 32bit: echo 'print(pcall(string.format, "%d", 2^63))' | lua5.1 true 2147483647 echo 'print(pcall(string.format, "%d", 2^63))' | lua5.2 true 9223372036854775807 echo 'print(pcall(string.format, "%d", 2^63))' | lua5.3 false bad argument #2 to 'string.format' (number has no integer representation) ...wow. I wonder how we've ever got 5.2 keyworded on all these arches in the first place! At least we've got some consistency here (the least said about 5.1 the better, especially given both its age and its abysmal test coverage). Okay, so what do you guys reckon we should do? 5.2 will hopefully no longer be a problem soon but the fact we've got Argh, the browser has somehow sent the page too early. Anyway, as I was saying - 5.2 will hopefully no longer be a problem soon but we've still got 5.1 to think of... I reckon that at this point we might just assume either that this only affects string.format or that it is a fact of life regarding this version of Lua), shrug and carry on as usual (and perhaps even keyword it on riscv after all, with lua5-1 still being the default target and all) - but I can't say I personally would be entirely happy with this. I think this is in the end same problem as the one I stumbled upon while attempting to keyword dev-python/xarray for riscv. In short: * numbers in Lua are all 64-bit floats; * ergo, 2^63 is - as described in the code - out of range; * the relevant string.format line casts its input to an integer. However, the result of casting a float64 NaN to an int is undefined in C; * what we see here is how different platforms handle such an undefined cast. Anyway, IMHO this issue is safe to close now. lua-5.2 is gone now, 5.3+ handle this operation differently under the bonnet, and I dare say we know what is going on with 5.1. |
