[AUTOMATED] feat(p9): ctypes - emit valid per-architecture C type names instead of the Ghidra core-type vocabulary (DIV-75)

[mahaloz]

The defect

The emitted "C" is not C, and it mixes two vocabularies inside a single function:

void BounceClass::Init(unsigned int a0,...,float8 a5,float8 a6)
{
  int4 v1;            // eax
  float4 v2;          // stack - 0x2c
  unsigned int v3;    // esi     <-- relabelled
  float8 v4;          // mm0     <-- not
  ...

kuna interns its core types under the literal names uint1/int4/float8/float10/code — a verbatim port of upstream's no-<coretypes> fallback branch (sleigh_arch.cc:204), which the real Ghidra application never takes because its Java side supplies its own names over the wire. The printer prints those names.

The DIV-6 realtypes relabel covers only residual TYPE_UNKNOWN, so xunknown4 renders unsigned int while the genuine TYPE_UINT core type uint4 beside it does not. That one early-out is the entire cause of the mixture.

The fix

One speller, at the one chokepoint. declarator_parts already funnels declarations, casts (push_cast_type), prototypes, struct members, array element types and the --json type_to_c_string; p9_emit/kuna_ctypes.rs (core_type_spelling) extends its existing relabel step from TYPE_UNKNOWN to every core type. A user-defined or DWARF-recovered type is untouched — its name is already C.

The rule is a port of Ghidra's DataOrganizationImpl.getIntegerCTypeApproximation: match the type's size against the target's own declared widths, in declaration order, first hit wins. Never a hard-coded 2/4/8 table. Declaration order is exactly what makes it per-architecture — under LP64 both long and long long are 8 bytes and an 8-byte integer must read long, while under ILP32/LLP64 long is 4 and the same size lands on long long. The widths come from #301.

Three cases are decided, not left to fall out of the table:

• A 1-byte integer is signed char / unsigned char, never bare char — its signedness is implementation-defined, and kuna reserves the char core type for text.
• code becomes void, so code * reads void *.
• Floating point is the one place an approximation is unavoidable: an exact width wins, but a width above double with no exact match spells long double. No target has a 10-byte sizeof — the x86 cspecs record 10 as the x87 value width and annotate storage in a comment — so this is an approximation of storage, deliberately the same one the recompile prelude already makes, since the .c and the .h must not disagree.

Integer widths with no C type at all (3/5/6/7, 16-byte) keep undefined<N> and are not widened: (undefined3)x is a 24-bit truncation and (unsigned int)x is not.

Why the printer and not the factory

Renaming the interned core types was rejected on the merits, not just on churn: a core type's id is hash_name(name); Ghidra-style identifiers derive from the first character of the type's name (float8 is what makes fVar1); and the console's C-type parser resolves base types solely through TypeFactory::find_by_name, with no unsigned/long keywords in its grammar — 269 <com> parse line script lines across 87 corpus files feed int4/float8 into exactly that path.

Result

void BounceClass::Init(unsigned int a0,...,double a5,double a6)
{
  int v1;             // eax
  float v2;           // stack - 0x2c
  unsigned int v3;    // esi
  double v4;          // mm0

Invalid-C type tokens in the emitted output, off → on:

binary	arch	off	on
bounce.obj (the report)	i386 MSVC COFF	301	1
grep	x86-64	5,153	11
i386_pie_nl	i386	667	0

Every survivor is an undefined3/undefined7 — a width no C type has, kept by design. Whole-binary sweeps on combat.obj, libselinux.so.1, fmt_aarch64 and mips_gp_le32 leave no core-type name at all.

Tests

The per-architecture claim is gated by comparison, not assertion: ctypes_per_arch decompiles x86-64 and i386 in one test and pins that LP64 spells an 8-byte unsigned unsigned long and never reaches long long, while ILP32 spells the same core type long long. Getting that backwards is the single most likely way a size→name table is wrong, and it is invisible on either target alone. A fourth test asserts the headline contract directly — no Ghidra core-type name survives on any of four data models — plus a 9-case unit suite over LP64/ILP32/LLP64 and a two-pass tests/stages/kuna-ctypes.xml.

Gating, and a limit worth naming

Shipped catalog default is off: 42 of the 675 datatest assertions and 43 stage assertions pin the Ghidra spellings, and the parity harness applies no mode — so both corpora are untouched, with no per-test opt-out and no baseline re-pin.

Preset membership is what makes valid C the real default: auto selects aggressive for anything under 500 KiB, i.e. for kuna decompile, decompile-all, decompile-project, the web front-end and the benchmark.

Known limit, recorded in the DIV row rather than left to be discovered: a binary at or above 500 KiB gets reliable, whose overrides are deliberately empty, so it keeps the Ghidra vocabulary. betaflight_STM32F405.elf at 533 KB is exactly such a case. Closing that means flipping the catalog default itself, which needs ~39 corpus opt-outs and is its own PR.

Speed: pure rendering, no measurable cost — interleaved, minimum of 3 on i386_pie_nl: on 1.641 s vs off 1.830 s (the on-arm is faster, i.e. below the noise floor).

Gates

• make test — 675/675 PARITY OK
• make test-stages — PARITY OK (460/460)
• make rust-test — green locally, 311 targets (internal PRs skip the workspace suite)
• make check-spec — green; kuna catalog --check — OK

Counters re-derived from the built artifact: live catalog 106, catalog_bytecompat.rs 106, kuna_phases/tests.rs 106 / tiers (23, 47, 36) / },\n 105 / live readers 33, phase_catalog.json 106, docs/options.md 106, xml.rs corpus 204.

🤖 Generated with Claude Code

https://claude.ai/code/session_01JyfU1KXNMWieY7HkFx2YbN