0.5.0 --- repin the C library, whose backends fixed a bounded transfer

[Sunrisepeak]

Repins the C library to openkal-musl 0.9.0, which answers truncate(2) (0.8.0), repins openkal-linux 0.7.1 and openkal-macos 0.6.1, and makes a build able to state which version of the C library it holds (0.9.0).

What a program above this package gets

Two things that did not work now do, and neither is a C++ problem — both are std::filesystem reaching a system call.

std::filesystem::copy_file reported Resource temporarily unavailable for two ordinary files. libc++ opens a copy's source with O_RDONLY | O_NONBLOCK | O_BINARY (operations.cpp:378), which on a kernel is meaningless for a regular file and is ignored. openkal-musl routes an O_NONBLOCK descriptor through the bounded-transfer path and expresses copy_file_range as a read/write loop, so every byte of a file copy went through it — and the backends' kal_timeout_read decoded a borrowed kal_stream handle with the decoder for an owned one, waiting upon the descriptor below the one it then transferred upon. EAGAIN is not in libc++'s fallback list for copy_file_range (operations.cpp:310-313), so it fell back neither to sendfile nor to a stream copy and the error reached the caller verbatim.

std::filesystem::resize_file worked for no path at all. libc++ expresses __resize_file as detail::truncate(p.c_str(), size) (operations.cpp:966) — the name-shaped call — and only the descriptor-shaped ftruncate had a case.

Both reported in mcpplibs/openkal-linux#13.

Also here

The two fetches of the xlings installer retry transport failures. --retry covers a transient HTTP status and a timeout; it does not cover curl: (35) Recv failure: Connection reset by peer, which is what a row of openkal-musl's matrix met today, thirteen seconds in, with nothing wrong in it. A red row that names a defect nobody introduced costs a reader the time it takes to establish that, every time.

And a consumer can now say what it built

$ OPENKAL_MUSL_TRACE=enosys ./your-program
openkal-musl 0.9.0

Named before the program runs and whether or not anything is missing. Two rounds of mcpplibs/openkal-linux#13 were answered against the wrong version because neither that line nor an honest uname release field existed. With the variable unset the library writes zero bytes to the error stream, asserted on every row.

Verified through the index, not through working trees

That is the only way to examine what a consumer receives — every repository in this family substitutes working trees for its dependencies in CI, so none of those runs examines the index entry, the archive, its hash, or the resolved graph.

One program, one source file, differing only in the version its manifest names:

openkal-musl = "0.7.0"      (index+mcpplibs@0.7.0 -> openkal-linux 0.7.0)
  note: 1 of 16 pipes reported readable
  FAIL: a pipe with a byte in it is reported readable
  -- failures: 1 --

openkal-musl = "0.8.0"      (index+mcpplibs@0.7.1 -> openkal-linux 0.7.1)
  ok: truncate(2) by name
  ok: the length set by name is reported
  ok: a pipe with a byte in it is reported readable
  -- failures: 0 --

Sixteen pipes, a byte written into each, poll(POLLIN) on each reading end. One of sixteen passed under the defect — the first, the only one whose N-1 was not the previous pipe's writing end.