Tim Lingo
f6aa072d5f
The Windows el runtime stashes the byte count of the last fs_read in a
thread-global (_tl_fs_read_len) so binary files (PNG/WOFF2) serve without
strlen truncation at embedded NULs. But it was consumed unconditionally:
any handler that fs_reads a file and then returns a DIFFERENT, longer
response (e.g. /api/safety-contact reads the 178-byte contact file, then
wraps it in {"configured":true,"contact":...,"ok":true}) had its reply
clipped to the file size — the client received truncated, invalid JSON.
Record the buffer the length belongs to (_tl_fs_read_ptr) and only trust the
byte count when the handler returns that exact buffer; otherwise measure the
built response with strlen. Fixes every fs_read-then-transform endpoint
(safety-contact GET/POST, etc.). macOS (native runtime) was unaffected.
Verified root cause on Windows 11: GET/POST /api/safety-contact returned
Content-Length 178 with a body truncated mid-JSON; macOS returned the full
208-byte body. This is why the Neuron Windows app could not save the safety
contact (and would fail most soul calls).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>