fed-sx-m1: Step 3b substrate fix — binary_to_list/1 + list_to_binary/1 BIFs (+9 ffi, 738/738)

next/README.md

@@ -103,11 +103,16 @@ The kernel calls into these host primitives: `crypto:hash/2`,
 
 These three gaps block the remaining unchecked deliverables:
 
-1. **Term codec** (`3b`/`3c`) — `atom_to_list`/`integer_to_list` return
-   SX-strings (an opaque OCaml-string type), not Erlang charlists;
-   `binary_to_list`/`list_to_binary` are unregistered; `$X` char literals
-   decode to `nil` in `parse-number`. Net effect: no in-Erlang term ↔ binary
-   round-trip path. Blocks on-disk log persistence.
+1. **Term codec** (`3b`/`3c`) — **byte-level path resolved 2026-06-04:**
+   `erlang:binary_to_list/1` and `erlang:list_to_binary/1` are now registered
+   in `lib/erlang/runtime.sx` (738/738 conformance, +9 ffi tests). `list_to_binary`
+   is iolist-aware (`[1, <<2,3>>, [4, [5]]]` → `<<1,2,3,4,5>>`); round-trip
+   `list_to_binary(binary_to_list(B)) =:= B` holds. Step 3b on-disk segment
+   writer is unblocked if it uses byte ints directly. Still parked:
+   `atom_to_list`/`integer_to_list` return SX-strings (an opaque OCaml-string
+   type), not Erlang charlists; `$X` char literals decode to `nil` in
+   `parse-number`. Both still block code that wants Erlang-idiomatic
+   `[$h,$i | T]` patterns on atom/integer names.
 
 2. **SX-source eval bridge** — There's no BIF that lets Erlang call into the
    SX evaluator on a parsed source string. Blocks evaluating the `:schema` /