You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
BigInt literals wider than 64 bits are truncated in split (multi-unit) modules: 2n ** 70n === 1180591620717411303424n is false #10545
Found by the package audit (while fixing #10418) on Perry 7661bc0 (v0.5.1589), Linux x64. When a module is compiled
as more than one codegen unit, BigInt literals that don't fit in 64 bits lose their high bits: a 71-bit literal
becomes 0n, a 97-bit negative literal becomes a different 64-bit value. Single-unit builds are correct. Large real
modules are split automatically, so this silently changes the constants of big BigInt-heavy libraries (crypto curve
parameters, field moduli), not just forced splits.
node main.ts
PERRY_NO_AUTO_OPTIMIZE=1 perry compile main.ts -o one && ./one # 1 unit
PERRY_CODEGEN_UNITS=2 PERRY_NO_AUTO_OPTIMIZE=1 perry compile main.ts -o two && ./two # forced split
The 64-bit literal 12345678901234567890n survives; anything wider is truncated.
Impact
Every automatically split module containing a >64-bit BigInt literal computes with wrong constants — silently.
Real candidates: @noble/curves (secp256k1/ed25519/BLS field primes and group orders are 255–381-bit literals), @noble/hashes constants, ethers, big-number libraries, and any large bundle that happens to include them.
The gap corpus is all single-unit, so no existing test covers this.
A split-mode variant of the gap harness (or a unit test that compiles a module with PERRY_CODEGEN_UNITS=2 and
checks wide literals) would catch the whole class of split-only IR regressions.
Activity
docs(changelog): fragment for #10545
docs(changelog): fragment for #10545