bun:ffi: make cc() reject non-numeric i64/u64 arguments instead of passing garbage

[robobun]

Problem

• A symbol compiled with cc() that declares an i64, u64, i64_fast or u64_fast argument and is given something that is neither a number nor a BigInt (undefined, null, a boolean, an object, a string) aborts debug builds with ASSERTION FAILED: value.isHeapBigInt() || value.isNumber() in JSC__JSValue__toInt64 (src/jsc/bindings/bindings.cpp:4366); release builds hand the C function INT64_MIN (signed types) or 0 (unsigned types).
• Cause: the wrapper cc() compiles converts these arguments with JSVALUE_TO_INT64 / JSVALUE_TO_UINT64 (src/runtime/ffi/FFI.h:314 and :329 on main). Both decode int32-tagged and double-encoded numbers inline and tail-call a slow path for everything else; the slow paths were JSC__JSValue__toInt64 and JSC__JSValue__toUInt64NoTruncate (bindings.cpp:4363, :4468), which only accept numbers and BigInts and read anything else as a double. The wrapper also had no way to report a failed conversion: it always went on to call the C function.
• Only cc() is affected. Since bun:ffi: use the engine-native FFI when available #35246, dlopen()/linkSymbols()/CFunction convert arguments in the engine (JSC::FFI::writeInt64Slot), which converts int32/double/BigInt and throws TypeError: bun:ffi cannot convert argument to 'i64' (the type's name) for anything else. cc() still calls through the TinyCC-compiled wrapper built from FFI.h.
• Distinct from the other open FFI.h fixes: bun:ffi: fix cc() integer argument decoding and the int32 boundary in FFI.h #37978 (int32-family arguments and the int32 box boundary), bun:ffi: stop cc() from turning non-numeric pointer arguments into garbage pointers #37989 (pointer-typed arguments) and bun:ffi: treat arguments not passed to a cc() symbol as undefined instead of reading past the call frame #38014 (missing arguments). bun:ffi: treat arguments not passed to a cc() symbol as undefined instead of reading past the call frame #38014 makes a missing i64 argument behave like an explicit undefined, i.e. it lands on this path.

Fix

• FFI.h: the int32 and double branches of JSVALUE_TO_INT64 / JSVALUE_TO_UINT64 are unchanged; their slow path is now JSVALUE_TO_SLOT_SLOW(globalObject, abiType, &threw, value), bound to the new Bun__FFI__jsValueToSlotSlow (JSCFFIBridge.cpp), which runs the engine's writeSlotFromJSValue for the argument's type, returns the 64-bit argument slot and sets *threw when the engine threw. The two bindings.cpp functions keep their other callers and are no longer handed to TinyCC.
• abi_type.rs: each row of the ABI table now carries its ABI_TYPE_* define name and says whether its conversion is Infallible (f(arg), as before) or Fallible (f(JS_GLOBAL_OBJECT, ABI_TYPE_X, &threw, arg)); the four 64-bit integer rows are Fallible. Function::compile defines every tag for the wrapper's compilation only (the user's C, compiled by CompileC::compile, does not see them), and print_source_code converts every Fallible argument into a local before the call, returning the empty JSValue (the host-function convention after a throw) as soon as one threw, so the C function is never entered with an exception pending; the napi handle scope, when there is one, is opened after these conversions. Another argument type that wants the same treatment only needs its row flipped to Fallible plus its own FFI.h inline function; bun:ffi: stop cc() from turning non-numeric pointer arguments into garbage pointers #37989 (pointer types) is that case, and this is the mechanism both fixes share.
• Why this is correct: the engine converter is the definition of what a bun:ffi 64-bit integer argument accepts (it is what dlopen() has run since bun:ffi: use the engine-native FFI when available #35246), so the values this change routes to it, BigInts and non-numbers, now get exactly dlopen()'s results and dlopen()'s TypeErrors; BigInts produce the same bits as before (toBigInt64/toBigUInt64 either way), so the only observable change is that inputs which previously aborted or produced garbage now throw. Numbers are not routed and their inline branches are untouched. That is deliberate: u64's double branch already differs from the engine for negative and non-finite numbers (TinyCC's unsigned conversion drops the sign), and the engine's own doubleToUInt64 mis-converts [2^63, 2^64) where cc() is right, so the two need one decision made together; that is tracked as a separate bug and this PR does not claim parity for them. The other pre-existing cc()-only extra, a TypedArray given to u64/u64_fast converting to its length, is likewise untouched and pinned by the test so the difference from dlopen() stays visible.
• Generated code: wrappers without 64-bit integer arguments produce the same C as before, except that napi wrappers now open their handle scope after loading the argument slots (reading slots creates no handles). test/js/bun/ffi/ffi.test.fixture.receiver.c is the checked-in viewSource() output regenerated by the ffi print test, as in bun:ffi: decode double-encoded JSValues in JSVALUE_TO_INT32 #34653 and ffi, napi: purify NaNs before NaN-boxing doubles from native code #32787.
• Overlaps textually with bun:ffi: fix cc() integer argument decoding and the int32 boundary in FFI.h #37978, bun:ffi: stop cc() from turning non-numeric pointer arguments into garbage pointers #37989 and bun:ffi: treat arguments not passed to a cc() symbol as undefined instead of reading past the call frame #38014 in print_source_code and the ABI table; whichever lands later rebases (bun:ffi: fix cc() integer argument decoding and the int32 boundary in FFI.h #37978 and bun:ffi: treat arguments not passed to a cc() symbol as undefined instead of reading past the call frame #38014 delete needs_a_cast_in_c(), which the call-site branch here still consults; bun:ffi: stop cc() from turning non-numeric pointer arguments into garbage pointers #37989 becomes four Fallible rows plus its FFI.h and test changes on top of this).
• Verified with test/js/bun/ffi/cc.test.ts, new 64-bit integer arguments block. The matrix test runs the same inputs (numbers, BigInts, eight kinds of non-numbers) through a cc() wrapper and through a CFunction over the same C functions for all four types and requires the tables to match; an (i64, u64) function shows which argument is reported when several are bad (left to right, like the engine) and, via a call counter, that a rejected argument stops the call before C; an (i32, i64, f64) function covers a fallible conversion between inline ones. A second test covers the bail-out in a napi_env wrapper. Both fail on the unfixed binary (release: garbage values and 8 native calls instead of 4 in the cc table while the engine table already matches; debug: the assertion abort above) and pass under the debug ASAN build, also with BUN_JSC_validateExceptionChecks=1.
  • bun bd test test/js/bun/ffi/: everything else passes except the pre-existing 5s timeouts of the dlopen() "integer identities" tests and the two worker-terminate tests, which take about 5s each under debug ASAN in this container and do not use cc().
  • test/js/bun/ffi/cc-fixture.js (uint64_t argument plus napi_env) still passes on the debug build.

Background

• cc() compiles the user's C with TinyCC and, per symbol, compiles a second small C file: FFI.h followed by a wrapper generated by Function::print_source_code (viewSource() prints it). JSC installs that wrapper directly as the host function for symbols.name; it reads the raw NaN-boxed argument slots from the call frame, converts them, calls the user's function and boxes the result. FFI.h is therefore C compiled at runtime, and anything it calls (add_symbol) or any constant it uses (define_symbols) has to be handed to TinyCC by CompilerRT::inject / Function::compile in ffi_body.rs.
• A JSValue is 64 bits that encode either an int32, a double, a few immediates (undefined, null, booleans) or a pointer to a heap cell (objects, strings, BigInts). FFI.h can tell numbers apart by their tag bits; a BigInt and a plain object are both just cells to it, which is why everything that is not a number goes to a slow path in the runtime.
• JSC::FFI::writeSlotFromJSValue (engine, FFIConversions.cpp) converts one JS argument into the 64-bit slot the native call thunk reads, given the argument's FFI::Type. ABIType in abi_type.rs uses the same numbering as FFI::Type (pinned by the static_asserts in JSCFFIBridge.cpp), so the tag the wrapper passes can be handed to the engine as is.
• A host function signals a throw in JSC by leaving the exception on the VM and returning; by convention it returns the empty JSValue (encoded as 0, ValueEmpty here), and the caller checks the VM's exception slot after the call. Running native code or further conversions with an exception pending is not allowed, hence the check after each conversion.

Repro from the report

// i64.c
long long echo_i64(long long x) { return x; }
unsigned long long echo_u64(unsigned long long x) { return x; }

import { cc } from "bun:ffi";
const { symbols } = cc({ source: "./i64.c", symbols: {
  echo_i64: { args: ["i64"], returns: "i64" },
  echo_u64: { args: ["u64"], returns: "u64" },
} });
console.log(symbols.echo_i64(undefined)); // 1.4.0: -9223372036854775808n   now: TypeError: bun:ffi cannot convert argument to 'i64'
console.log(symbols.echo_u64(undefined)); // 1.4.0: 0n                       now: TypeError: bun:ffi cannot convert argument to 'u64'

Debug build before the fix:

ASSERTION FAILED: value.isHeapBigInt() || value.isNumber()
../../src/jsc/bindings/bindings.cpp(4366) : int64_t JSC__JSValue__toInt64(JSC::EncodedJSValue)

null, true, {}, "12", () => 1 and a TypedArray (for i64) behave the same way as undefined before and after; numbers and BigInts are unchanged. The same definitions through CFunction over the compiled function's address throw the TypeErrors shown above both before and after.

Earlier revision

The first revision (8cb84c3) had the same fix but wired it specifically to the 64-bit integer types: an int64-only bridge function, a hand-written list of four tag defines, and a hard-coded list of throwing types. Self-review pointed out that #37989 needs the identical plumbing for pointer types, that the two-argument test could not tell which argument had thrown (both were i64), and that the body over-claimed parity for u64 doubles. 66691e3 made the mechanism table-driven as described above, changed the multi-argument tests, and scoped the parity claim; da48000 shortened comments.

[robobun]

^{Updated 4:33 AM PT - Aug 13th, 2026}

@robobun, your commit da48000 is building: #94689

[coderabbitai]

Warning

Review limit reached

@robobun, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 13 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: e3a0458c-52d4-4930-8024-4af04ffbe075

📥 Commits

Reviewing files that changed from the base of the PR and between 04148c8 and da48000.

📒 Files selected for processing (6)

• src/jsc/bindings/JSCFFIBridge.cpp
• src/runtime/ffi/FFI.h
• src/runtime/ffi/abi_type.rs
• src/runtime/ffi/ffi_body.rs
• test/js/bun/ffi/cc.test.ts
• test/js/bun/ffi/ffi.test.fixture.receiver.c

---

_{Comment @coderabbitai help to get the list of available commands.}

[robobun]

Status: fix and tests pushed (reworked after self-review, see the "Earlier revision" note in the description), waiting on CI.

Reproduced on 1.4.0 with an i64/u64 echo function compiled by cc(): echo_i64(undefined) returned -9223372036854775808n and echo_u64(undefined) returned 0n, while a CFunction over the same compiled function threw TypeError: bun:ffi cannot convert argument to 'i64' / 'u64'. A debug build aborted with ASSERTION FAILED: value.isHeapBigInt() || value.isNumber() in JSC__JSValue__toInt64 (bindings.cpp:4366). With this branch the cc() wrapper throws the same TypeErrors as the CFunction path, and test/js/bun/ffi/cc.test.ts ("64-bit integer arguments") fails on the unfixed binary and passes on the debug ASAN build.

[claude]

I reviewed this PR and didn't find any bugs. Because it touches the FFI/JSC bridge (runtime-generated C, host-function exception protocol, and a new extern "C" slow path), a human look would still be worthwhile.

What was reviewed:

• to_c() call sites — both are in print_source_code and either declare threw beforehand or branch on arg_conversion_can_throw() first; print_callback generates no C source.
• Handle-scope reordering — throwing conversions now run before NapiHandleScope__open, so the early return ValueEmpty has nothing to close; slot loads and writeSlotFromJSValue create no napi handles.
• ABI_TYPE_* defines are added in Function::compile (wrapper only), not the user's CompileC::compile; the removed JSVALUE_TO_UINT64_SLOW symbol is no longer declared in FFI.h.

Extended reasoning...

Overview

This PR fixes cc()-compiled FFI wrappers so that i64/u64/i64_fast/u64_fast arguments given non-numeric values throw a TypeError (matching dlopen()/CFunction) instead of aborting debug builds or passing garbage in release. It touches: a new extern "C" bridge (Bun__FFI__jsValueToInt64Slow in JSCFFIBridge.cpp) that delegates to the engine's writeSlotFromJSValue and reports whether it threw; signature changes to JSVALUE_TO_INT64/JSVALUE_TO_UINT64 in the TinyCC-compiled FFI.h; ABI-table and wrapper-codegen changes in abi_type.rs/ffi_body.rs so throwing conversions run into locals first and the wrapper returns ValueEmpty before entering C or opening a napi handle scope; ~230 lines of new tests plus a regenerated viewSource() fixture.

Security risks

None new. The change replaces an unchecked slow path (which read arbitrary JSValues as doubles) with a checked one that throws for non-numbers/BigInts. The generated wrapper now correctly follows the JSC host-function convention on throw (return the empty JSValue with the exception pending). The ffiContext() accessor and writeSlotFromJSValue are the same machinery dlopen() already uses.

Level of scrutiny

High. This is native FFI/JSC bridge code: runtime-compiled C that reads raw NaN-boxed call-frame slots, a new C++/Rust ABI boundary, and control-flow changes in generated wrappers around JSC exception handling and napi handle scopes. Getting the throw protocol or handle-scope ordering wrong would be a memory-safety or exception-scope-verification failure. While the change is well-designed and thoroughly tested (matrix over four types × fourteen inputs × two entry points, a two-arg call counter proving C isn't entered, a napi_env variant, and BUN_JSC_validateExceptionChecks=1), it is not simple or mechanical enough for auto-approval.

Other factors

The PR description explicitly notes textual overlap with three other open FFI.h PRs (#37978, #37989, #38014) in print_source_code and the ABI table — a maintainer should be aware of the merge/rebase order. I verified that the only two to_c() call sites are both correctly guarded (the pre-conversion loop declares threw; the call-site loop uses converted{i} for throwing types), that the callback direction doesn't generate C source, and that the removed JSVALUE_TO_UINT64_SLOW TinyCC symbol has no remaining reference in FFI.h.

[claude]

I reviewed this PR and didn't find any bugs. Because it reworks the cc() wrapper code-gen (new ToC::Fallible mechanism, moved napi handle-scope open, a new C++ bridge into writeSlotFromJSValue) and is one of four overlapping FFI.h fixes that need to land in a coordinated order, a human look is still warranted.

What was reviewed:

• ToCFormatter's Fallible arm is only reached from the pre-conversion loop where bool threw is in scope; the call-site loop routes fallible args to converted{i} first.
• define_symbols signature matches tag_defines()'s [(&str, i64); 22]; the defines are added only in Function::compile, not in the user's C compilation.
• Early return on throw happens before NapiHandleScope__open, so no scope leaks; BufferLength reaching unreachable!() in the Special arm is pre-existing, not introduced here.
• Bun__FFI__jsValueToSlotSlow uses DECLARE_THROW_SCOPE + scope.exception() and only writes *threw on the throw path (the wrapper zero-initialises it).

Extended reasoning...

Overview

The PR routes the slow path of cc()'s 64-bit integer argument conversion through the engine's JSC::FFI::writeSlotFromJSValue (the same converter dlopen()/CFunction use), so non-numeric/non-BigInt inputs now throw the engine's TypeError instead of aborting debug builds or passing garbage in release. Mechanically: FFI.h's JSVALUE_TO_INT64/UINT64 gain (globalObject, abiType, &threw) params and tail-call a new JSVALUE_TO_SLOT_SLOW symbol bound to Bun__FFI__jsValueToSlotSlow; abi_type.rs gains a ToC enum (Infallible/Fallible/Special) plus per-row tag_define names; print_source_code in ffi_body.rs now converts fallible arguments into locals before the native call, checking threw after each and returning ValueEmpty on throw, and opens the napi handle scope only after conversions succeed. CompilerRT::inject swaps the two removed slow-path symbols for the new one, and Function::compile #defines all 22 ABI_TYPE_* tags. The regenerated ffi.test.fixture.receiver.c reflects the header change; the two new cc.test.ts blocks cover the input matrix against both cc() and CFunction, multi-arg ordering, native-call suppression, mixed fallible/infallible signatures, and the napi_env bail-out.

Security risks

None identified. The change tightens input validation (rejecting inputs that previously passed garbage to native code), does not expose new surface, and the ABI-type tag passed to the engine converter is a compile-time constant baked into the generated C, not user-controlled.

Level of scrutiny

High. This is FFI code-generation and JSC exception plumbing across a TinyCC-compiled boundary — a mistake here can crash or corrupt callers of any cc() symbol with an i64/u64 parameter, and the wrapper C is compiled at runtime so type mismatches are not caught by the host toolchain. The change also introduces a table-driven mechanism (ToC::Fallible) explicitly intended as the shared foundation for three other open PRs (#37978, #37989, #38014); a maintainer should confirm this is the shape they want before those PRs rebase onto it.

Other factors

The tests are unusually thorough (matrix comparison against CFunction over the same C, native-call counter, napi_env variant) and the description documents verified failure on the unfixed binary and success under debug ASAN with BUN_JSC_validateExceptionChecks=1. All comment-cop bot findings were addressed in da48000 and are marked resolved. I checked that removing the WORKAROUND struct fields for the old slow paths leaves the remaining two int64→JSValue functions intact, that the Special arm's unreachable!() for BufferLength is unchanged from before, and that the moved handle-scope open cannot skip a matching close (the only early return is before it opens). The remaining reasons to defer are the design sign-off on the Fallible mechanism and merge ordering with the three overlapping PRs, not correctness concerns.

[robobun]

Heads up: #39124 (merged, 454b1ca) removed ABIType::param_typename from src/runtime/ffi/abi_type.rs since it was a copy of ABIType::typename. This branch adds a call to it in print_source_code (ffi_body.rs), so it will not compile against current main until that call is changed to arg.typename(writer). Same output, the two methods wrote the same bytes.