Gap
The sync call-lowering class dispatch selects Transcode only when the boundary crosses memory (site.crosses_memory && options.needs_transcoding()). crosses_memory is set purely from the memory strategy (resolver.rs:2866-2879) — under --memory shared it is always false, independent of string encoding.
So a sync, same-memory, mixed-encoding call (e.g. a UTF-8 component calling a UTF-16 component fused with --memory shared) routes to AdapterClass::Direct — a thin shim that does not transcode — and the string bytes are delivered verbatim in the wrong encoding. No upstream validation rejects mixed encodings under shared memory (only the LS-P-17 warning).
This is the sync twin of the async case, which meld already fails loud on: guard_async_cross_encoding_strings (fact.rs:12139, #272) — "async cross-encoding string transcoding is not yet supported".
Reachability
Legal input: two components with different canonical string-encoding options fused with --memory shared. Silent semantic drift (H-class: fused output diverges from composed input). Pre-existing; surfaced by the auto-Mythos delta-pass on the call-lowering seam (#360).
Immediate mitigation (in #360)
The call-lowering seam (adapter::call_lowering::resolve_call_lowering_plan) now hard-fails on needs_transcoding && !crosses_memory, mirroring the async guard — turning the silent miscompile into a loud, tested AdapterGeneration error. This closes the silent-corruption hazard.
This issue tracks the capability
Actually supporting same-memory string transcoding (a Transcode-class adapter that transcodes in place / into a scratch buffer within the shared memory, without the cross-memory cabi_realloc + memory.copy assumption) so the hard-fail can be lifted. Fits the ADR-7 path-H per-boundary call-lowering seam: a same-memory-transcode boundary is a distinct lowering the seam should eventually resolve to a real adapter rather than reject.
Refs #360, #272, ADR-7 (path-H inc 2).
Gap
The sync call-lowering class dispatch selects
Transcodeonly when the boundary crosses memory (site.crosses_memory && options.needs_transcoding()).crosses_memoryis set purely from the memory strategy (resolver.rs:2866-2879) — under--memory sharedit is always false, independent of string encoding.So a sync, same-memory, mixed-encoding call (e.g. a UTF-8 component calling a UTF-16 component fused with
--memory shared) routes toAdapterClass::Direct— a thin shim that does not transcode — and the string bytes are delivered verbatim in the wrong encoding. No upstream validation rejects mixed encodings under shared memory (only the LS-P-17 warning).This is the sync twin of the async case, which meld already fails loud on:
guard_async_cross_encoding_strings(fact.rs:12139, #272) — "async cross-encoding string transcoding is not yet supported".Reachability
Legal input: two components with different canonical
string-encodingoptions fused with--memory shared. Silent semantic drift (H-class: fused output diverges from composed input). Pre-existing; surfaced by the auto-Mythos delta-pass on the call-lowering seam (#360).Immediate mitigation (in #360)
The call-lowering seam (
adapter::call_lowering::resolve_call_lowering_plan) now hard-fails onneeds_transcoding && !crosses_memory, mirroring the async guard — turning the silent miscompile into a loud, testedAdapterGenerationerror. This closes the silent-corruption hazard.This issue tracks the capability
Actually supporting same-memory string transcoding (a
Transcode-class adapter that transcodes in place / into a scratch buffer within the shared memory, without the cross-memorycabi_realloc+memory.copyassumption) so the hard-fail can be lifted. Fits the ADR-7 path-H per-boundary call-lowering seam: a same-memory-transcode boundary is a distinct lowering the seam should eventually resolve to a real adapter rather than reject.Refs #360, #272, ADR-7 (path-H inc 2).