[Neoky]

Hi, I'm Neoky, and I'm a cyber researcher. I've been developing a new tool to check for type safety and it found some issues with elk that I've patched.

do_op: apply the ToInt32/ToUint32 coercion the language specifies

Fixes #80.

do_op() converts operands with (long) before computing. That is undefined in C
whenever the value is out of range (C11 6.3.1.4) or a shift count is negative or
≥ the operand width (C11 6.5.7), and for ===/!== it is also simply wrong —
(long)1.5 == (long)1.7, so 1.5 === 1.7 is currently true.

ECMAScript specifies these operators: &, |, ^, ~, <<, >> apply
ToInt32/ToUint32 (a defined modulo-2^32 conversion), the shift operators mask the
count to its low five bits, and === compares doubles. This is that coercion, not
hardening added on top.

Changes

• & | ^ ~ << >> go through to_int32/to_uint32; shift counts are
  masked to 5 bits, and << goes through the unsigned type widened to 64 bits so
  integer promotion cannot overflow an int.
• === / !== compare as doubles, like the relational operators already do.
• % keeps computing a - b * trunc(a / b); only the undefined (long) cast is
  replaced. Operands that would yield a NaN are refused, the way TOK_DIV already
  refuses a zero divisor — see the note on Type Confusion: Positive NaN is misinterpreted as T_CODEREF #72 below.

Behavior changes

These are user-visible. Each is the answer the specification gives:

expression	before	after
2147483648 | 0	2147483648	-2147483648
4294967296 | 0	4294967296	0
1e21 | 0	-9.2233720368547758e+18	-559939584
~2147483648	-2147483649	2147483647
1 << 31	2147483648	-2147483648
1 << 32	4294967296	1
1.5 === 1.7	true	false
0.5 === 0	true	false
5 % 0	5	ERROR: bad % operands

Undefined behavior is also removed where the observed output does not change —
1 >> (0 - 1) and 1 << 66 both print the same value before and after, but only
the second is defined.

No new dependency

elk links no math library on any target, so ToUint32 reads the exponent and
mantissa out of the double rather than calling fmod()/trunc(). nm shows no
fmod, trunc, pow or sqrt in the object. The bit version was checked against
fmod(trunc(d), 2^32) over two million random doubles plus the boundary cases, with
no difference.

That is also why % is not an exact remainder: fmod() would be, and fmod() means
libm. If you would rather have exact % and accept -lm, it is a one-line change —
happy to switch it.

Testing

• make -C test test and make -C test test++ pass. C++ warning count is unchanged
  at 1 (the pre-existing -Wdangling-pointer on js->cstk = &res in js_eval).
• Not run locally: uno, vc2017, vc22, mingw.
• Unrelated heads-up: on a current toolchain make -C test test fails at
  unit_test.c:193 on master as well. ASan relocates locals to its fake stack, so
  the css probe in setlwm() ((char *) js->cstk - (char *) &n) returns 0 and the
  c > 0 assertion fires. ASAN_OPTIONS=detect_stack_use_after_return=0 restores it
  (css 0 → 2112). Not caused by this PR; glad to send it as a separate one-liner.

Not addressed

The value representation, which is #71 and #72: is_nan() requires the sign bit to
be clear, so a positive NaN or inf decodes as T_CODEREF rather than as a number, and
1e308 * 10 evaluates to an empty object. % refusing NaN-producing operands works
around that rather than fixing it; a real fix needs a representation that can hold NaN.