[colbymchenry]

Summary

The C function-pointer pass (fn-pointer-dispatch) now links a table's registered handlers only to functions in C and C++ files. Before, a C table could link to a Python or Rust function that shares the handler's name, and that function could also take the place of the real C handler.

Root cause

resolveFn in src/resolution/c-fnptr-synthesizer.ts looks a registered name up with ctx.getNodesByName(name), filtered only to function and method kinds. In a repository that also has Rust or Python, the candidates included those languages' functions. A registered name with no C function node behind it, like gen_probe in the test, landed on the foreign function. With several candidates, the first wins unless one is in the registering file, so a Python impl_read that sorted first took the place of the C impl_read the table names. Both reproduce on main with the PR's test.

What came from the contributor, and what we changed

From @bompus, unchanged: the filter (C_CPP_EXT.test(n.filePath), the pass's own scan set, so a header the language detector labels Objective-C still counts) and the test.

Ours:

• CHANGELOG. The bullet moved out of the released [1.6.1] section into [Unreleased] and was reworded.
• Objective-C .m/.mm files stay out, as the PR has it. The pass never reads a table or dispatch in a .m file. Allowing those files as targets would let an Objective-C method named init or read stand in for a C handler of that name, the same cross-language mistake this fixes. On GLFW, which mixes C and Objective-C, main links 354 table entries and none into a .m file. Its one C table that names a .m function, _glfwConnectCocoa in platform.c, is an anonymous-struct table that main doesn't bridge either.

Validation

• Linux kernel subtree (d135ab45: rust/, drivers/android, drivers/base, drivers/net/dsa, fs, tools/net, include/linux; 6,580 files, under the big-index rule): the graph is byte-identical on both arms, with 12,244 fn-pointer-dispatch edges, all into C or C++ files. On current main this tree has no edge into Rust or Python, so the PR's 193, from a whole-kernel index on its fork, don't show here.

  • A smaller tree holding the PR's three example sites has none either: pmcraid's ->reset_cmd = cmd, afs's ->update_time = new and map.c's p->lock = lock, with rust/ and tools/net/ynl. On main, a plain assignment of a variable doesn't register; only struct-value initializers, arrays and propagation between function-pointer fields do.
  • The whole kernel is beyond the big-index rule here, so the fix's effect is shown by the test: a C table and a same-named Python function, which main links wrongly.

• Red→green. The new case in c-fnptr-synthesizer.test.ts fails on main, where impl_read links to aaa/gen.py, and passes here; the suite has 19/19.

• Controls. C and C++ graphs are byte-identical (dump-graph, every table): redis 7f440372 (863 fn-pointer edges), GLFW 92dcf4ce (354), jq 49fbca12, leveldb 7ee830d0.

• Kernel parity. The change is TS-side: the kernel ports only the pass's per-file sweep, not its linking, so both engines take the same edges. kernel-parity.mjs on the kernel's drivers/base, drivers/net/dsa and drivers/android (279 C files) gives 240 at byte parity, 0 with diffs and 39 deferred to wasm by policy.

• Full suite: 762 files passed, 6 skipped; 9,075 tests passed, 85 skipped, 0 failed, on ece90943 (the same patch, one rebase earlier; the rebase brought only perf(resolution): read a bare JS/TS call's local binding once per match — graph byte-identical #2934, which touches name-matcher.ts).

Lands #1989 by @bompus.

🤖 Generated with Claude Code