Sam Sung 18ab7d8481 math.sin, math.cos and math.tan answer past the x87's range as 1.12.1 (#2019) ...

On Windows, `vm_parity`'s cos sweep failed on one item, `cos(1e300)`, whose last digit was the host libm's. 1.12.1 never computes it. `math_sin`, `math_cos` and `math_tan` are a bare `fsin`, `fcos` and `fptan` (`0x7fae1d`, `0x7fae4d`, `0x7fae7d`), and a finite operand of 2^63 or more is outside the x87's range and is left unchanged:
- `math.sin(1e300)` and `math.cos(1e300)` answer `1e300`;
- `math.tan` answers `-1.#IND`: `fptan` pushes nothing, so the pop at `0x7fae84` takes the operand and `0x7fae86` stores from an empty stack.

benilla-lua now answers the same. The sweep's recorded answers for that argument are the reference's, the same on every platform.

Test: the parity sweep's `1e300` items for `math.sin`, `math.cos`, `math.tan` and their degree forms.

Fixes #1999

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

2026-10-20 06:09:26 +07:00

..

examples

benilla-lua's VM and compiler behave as the client's Lua 5.0 (#1768)

2026-10-17 11:07:05 +07:00

src

math.sin, math.cos and math.tan answer past the x87's range as 1.12.1 (#2019)

2026-10-20 06:09:26 +07:00

tests

StatusBar bits, index usage lines, stack names and cursors follow 1.12.1 (#1959)

2026-10-19 02:48:36 +07:00

Cargo.toml

Run the script host on benilla-lua; remove the vendored C Lua and mlua (#1255)

2026-10-17 08:51:37 +07:00

GRAMMAR.md

The Lua library answers as 1.12.1's does (#1862)

2026-10-18 10:35:43 +07:00