Skip to content

feat(decompiler): Rec 34 #34-6c — host-side v1 request encoders for the six non-DecompileAt commands#225

Merged
CryptoJones merged 1 commit into
masterfrom
feat/34-6c-host-command-encoders
Jun 1, 2026
Merged

feat(decompiler): Rec 34 #34-6c — host-side v1 request encoders for the six non-DecompileAt commands#225
CryptoJones merged 1 commit into
masterfrom
feat/34-6c-host-command-encoders

Conversation

@CryptoJones
Copy link
Copy Markdown
Owner

Closes #224.

The Java half of #34-6, mirroring DecompileRequestCodec (#34-4): a new
CommandRequestCodec provides one static encoder per non-DecompileAt command
RegisterProgram, DeregisterProgram, FlushNative, StructureGraph,
SetAction, SetOptions — each building the v1 FlatBuffers payload the C++
worker decodes (#34-6a/#34-6b). With this, the request-encode/decode pair
exists end-to-end for every command in the schema.

Encode-only. In the protocol the host writes requests and the worker reads
them, and the vendored flatbuffers-java bindings are generated without a
verifier, so a host-side decoder would have no production caller and could not
safely reject a malformed buffer anyway (the worker's verified decode is covered
by the C++ testipc_lifecycle_codec.cc / testipc_config_codec.cc).

Wire details. None of these tables is the schema root_type (only
DecompileFunctionRequest is), so the generic FlatBufferBuilder.finish(int)
roots the buffer rather than a generated finish*Buffer helper. A null
argument leaves its field unset (read back as null), distinct from a
present-but-empty string.

Test-only and inert. Nothing in DecompileProcess calls this yet — the
command-loop wiring is the end-to-end-only change deferred per DD-0005.

Test plan

  • gradle :Decompiler:test green locally (JDK 21, --no-configuration-cache)
  • New CommandRequestCodecTest (14 tests) passes: round-trip + null-vs-empty for all six commands
  • DecompileRequestCodecTest still green (no regression)
  • CI green on both forges

Proudly Made in Nebraska. Go Big Red! 🌽 https://xkcd.com/2347/

…pileAt commands (#34-6c)

Java half of #34-6, mirroring DecompileRequestCodec (#34-4). A new
CommandRequestCodec provides one static encoder per command —
RegisterProgram, DeregisterProgram, FlushNative, StructureGraph,
SetAction, and SetOptions — each building the v1 FlatBuffers payload the
C++ worker decodes (#34-6a/#34-6b).

Encode-only: in the protocol the host writes requests and the worker
reads them, and the vendored flatbuffers-java bindings are generated
without a verifier, so a host-side decoder would have no production
caller and could not safely reject a malformed buffer anyway (the
worker's verified decode is covered by the C++ test*ipc_*codec.cc). None
of these tables is the schema root_type (only DecompileFunctionRequest
is), so the generic FlatBufferBuilder.finish(int) roots the buffer rather
than a generated finish*Buffer helper. A null argument leaves its field
unset (read back as null), distinct from a present-but-empty string.

A new fast-suite test (CommandRequestCodecTest) reads each payload back
with the generated accessors to pin the round-trip and the null-vs-empty
contract. Test-only and inert, like the rest of #34-4..#34-6: nothing in
DecompileProcess calls this yet — the command-loop wiring is the
end-to-end-only change deferred per DD-0005.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@CryptoJones CryptoJones merged commit cb2e2e9 into master Jun 1, 2026
14 checks passed
@CryptoJones CryptoJones deleted the feat/34-6c-host-command-encoders branch June 1, 2026 04:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Rec 34 (#34-6c): host-side v1 request encoders for the six non-DecompileAt commands

1 participant