TL;DR: We ported GoogleChromeLabs/jsbi — a pure-JS arbitrary-precision integer library — to modern C++17, bridged back to Node via N-API, for Port Mortem 2026 (Track H). The port itself wasn't the hard part. Proving it behaved identically to the original — and being honest about the one place we couldn't prove that — was.
This is the story of a compile error that was secretly a correctness bug, a shared_ptr that lied about owning memory, and a benchmark that changed its mind three times in a row, and what we did when it wouldn't sit still.
Why JSBI → C++, of all pairs
JSBI isn't really a JavaScript library. It's V8's internal MutableBigInt — written in C++ — manually downgraded to 30-bit digits so its arithmetic could survive inside JavaScript's 2^53 safe-integer ceiling without silently losing precision. Every multiply in the original source carries a 15-bit split trick that exists for exactly one reason: JS numbers can't safely hold the product of two 32-bit values.
So porting it back to C++ isn't a random language swap for Track H credit. It's undoing a constraint. In C++, a uint64_t accumulator holds that same product natively — no split needed. We weren't rewriting an algorithm. We were giving one back its native width.
