Op Sa. 11 Mei 2019 om 01:38 het Egor Skriptunoff
<egor.skriptunoff@gmail.com> geskryf:
> According to Lua manual, math.abs() must return the absolute value of its argument.
> Obviously, math.abs(math.mininteger) not equals to the absolute value.
> That's a bug.
>
> "bug" means that behavior does not match documentation.
> Either behavior should be changed (to return correct result)
> or documentation should be changed (to claim math.abs as returning result modulo 2^64 instead of the correct result)
In view of the fact that math.abs(math.mininteger) _can_ be
represented exactly as a lua_Number, I must agree with you.
I tried coding this case. It is suprisingly tricky.
fprintf(stderr,"n=%lli x=%llx <≤=≥>:%i%i%i%i%i\n",n,n,n<0,n<=0,n==0,n>=0,n>0);
if (n<0) n=-n;
fprintf(stderr,"n=%lli x=%llx <≤=≥>:%i%i%i%i%i\n",n,n,n<0,n<=0,n==0,n>=0,n>0);
produces (GNU compiler):
n=-9223372036854775808 x=8000000000000000 <≤=≥>:11000
n=-9223372036854775808 x=8000000000000000 <≤=≥>:01010
What you show here is a bug of the C compiler in its optimizer: given that the printed values "n=... x..." are the same before and after negating, but different when you perform tests on n in other parameters of the C "fprintf" function, you have here the effect of an unexpected caching for the value of n, and the order of evaluation of parameter values, which is not consistant (the optimizer got too far when comparing n with zero, or precomputed these tests before the "if(n<0)..." instruction and then passed the wrong value)
I don't know how you compiled it, but if you got "<≤=≥>:11000" in the first line and "<≤=≥>:01010" on the second line, the value of n displayed in "n=..., x=..." MUST be different.
Or you did not declare "n" as a C integer but using some bogous custom class instead (which overrides some operators but not all: this custom type is not fully comparable)...
I tried just compiling your example using only an "int n;" or "long n;" declaration (and all other basic integer types of various size), and no custom class at all (or other incorrect macros transcluded from your platform headers, possibly patched by you), and I get consistant results, even with GCC, in C like in C++ and various other dialects, and as well in Java, J#, C#...
So it's very likely that your test was not performed on standard C/C++ integer types or that your host platform is incorrectly installed (incorrectly patched "standard headers): check your installation, or reinstall GCC in a clean environment (including all its standard headers, and the headers of your Linux kernel version). If needed, create a new Linux machine to isolate it: there are good distributions whose goals is not to support a complete graphical UI, but just to support a basic shell console (with almost no services, no browsers, no audio/video/multimedia, no web integration, no X11, only a single local filesystem and a telnet or serial session adapter) just used to install and run compilers (suitable for rebui_lding a new kernel image for example).
Or you have a severe bug in your CPU (or its loaded microfirmware) !
Before compiling your Lua implementation on your platform, you should run the safety tests to make sure you get consistant results. Otherwise your Lua implementation will report the same bugs at run time: its the basic work you need to do on your platform to make sure it satisfies some constraints (and if not, you'll not to add a compatibility layer of patches: it is possibly in that step that you defined a custom type for some part of the Lua host adapter, but without scoping it to only the cases where these patches are really needed, and what you did had unexpected effects on other parts of the code and you did not check it).
I think that a Lua builder should have a standard set of safety tests that it must satisfy, with dependencies that must be satisfied by order of priority (any other bugs occuring later because of a high priority test that failed, must NOT be corrected by a patch at that later stage, but on prior stage you forgot to check).
Even GCC itself is compiled with a set of tests that must be met in order, before going on and declaring that compilation succeeded. The same should be true for compiling your Lua engine.
