[tae898]

Closes #323. Part of #315 and the glue changes of the wheels-only 26.11.1.post1. Nothing changes for users: every reply decodes to the same text and the same floats, and the same errors are raised.

What changes: the native wheel read each library reply with ctypes.string_at (a bytes copy), cut the float tail marker out of it (a second and third copy of the bytes), decoded it to str (another copy), and only then parsed it. It now decodes straight from the reply's address with PyUnicode_FromStringAndSize (strict UTF-8, the same UnicodeDecodeError as bytes.decode), so the text is copied once, into the str that json.loads reads. For a reply with a float32 tail only the last 40 bytes (to find ,"bin":N}) and the N floats are copied as bytes; the marker's comma is overwritten with } in the reply's own memory before the decode, so the slice and concatenation of the text are gone. The three readers (call, call_bin, exec_query) share one function, lib._take, which replaces two near-duplicate copies.

Lifetime: I did not make a garbage-collected owner object. A reply never outlives the call that takes it (the text becomes a str and the floats a copy before the call returns), so nothing can hold a view of the freed memory, and a finalizer would have to free from any thread or at interpreter exit, when the isolate thread handle may be gone. The free is in the finally of _take: exactly once, also when the decode or the tail parse raises. A NULL reply raises ArcadeDBError and frees nothing. The float tail is still one bytes copy because it must be read before the free; making it a view would need the owner object above.

Platforms: the reader needs the length of a NUL-terminated reply, and strlen comes from libc (ctypes.CDLL(None) on Linux and macOS) or msvcrt (ctypes.cdll.msvcrt on Windows) through ctypes, and the decode uses PyUnicode_FromStringAndSize from ctypes.pythonapi, a CPython C-API function. The new tests passed on the native parity legs for linux-x86_64, linux-aarch64 and windows-x64 (Python 3.12 and 3.14). PyPy and GraalPy were not checked: I do not know whether their ctypes.pythonapi offers that function, so on them the reader is unverified.

Peak memory does not rise: the bytes copy is gone and nothing new is held.

Tests (tests/test_native_reply_reader.py, native backend only, run in the native CI legs): each case (ASCII, non-ASCII with 2, 3 and 4 byte sequences, a 5 kB text, short texts, every alignment padding of the tail, a marker-like text deep in the reply) is read by _take and by a private copy of the former reader from two identical replies in the library's own memory, and the text, the floats and the pointer freed must agree. Spies check that a text reply makes no ctypes.string_at call at all (the former reader made one with the whole reply), that a reply with a tail asks only for 40 bytes and the floats (never the 5 kB text), and that arcadedb_free runs once with the pointer that was read, also for invalid UTF-8 (including an encoded surrogate), a bad tail count, and the public call and call_bin. A NULL reply is covered too (ArcadeDBError, no free), as is invalid UTF-8 in both the text-only and the tail form (three byte strings, one of them an encoded surrogate). The golden test tests/test_cross_wheel_golden.py is untouched. I could not run any of it here (CI only); the evidence is the runs listed below.

No speed claim: the measurement is a later laptop A/B, and the untimed profile studies queued for tonight.

🤖 Generated with Claude Code