D349 - The POSIX spellings were unserved, and they are the same functions
decided · 2026-08-27 · found by asking what titles import that nothing declares
Four titles import fourteen system libraries this project declares
nothing for. Two of them dwarf the rest and neither is system software -
graphics at three hundred and eighteen imports, online services at
around a hundred and ninety. libScePosix is the
OS-layer one, at forty-nine.
None of the forty-nine was served. Not because the behaviour was
missing - because the name was. A title imports
pthread_create from libScePosix and
scePthreadCreate from libkernel, a NID is the
hash of a name, and only one of those was declared. Twenty-four of them
have a vendor-named twin this project already implements and has done
for a long time.
So orbistoun-posix declares all forty-nine and serves
twenty-four by delegation: each resolves to the same
function pointer the vendor name resolves to, looked up from the
implementing crate's own table. Nothing is copied, so the two spellings
cannot drift, and arities come from the vendor declaration for the same
reason.
What the return convention costs, and what is not invented
POSIX answers zero or an errno; the vendor calls answer their own codes. The success paths coincide and the failure paths do not.
Nothing here invents an errno. A failure returns this project's
placeholder, which deliberately avoids the high bit so it can never be
mistaken for an established value. A guest testing != 0
behaves correctly; one switching on specific errno values falls to its
default branch rather than matching the wrong case. Worse than a real
errno, much better than a plausible guess, and it improves the day
somebody reads the values out of FreeBSD's own headers - which is a
citable source this project is entitled to use.
Three things the tooling caught, all of them mine
The mapping is mostly mechanical -
pthread_mutex_lock to scePthreadMutexLock -
and mostly is the problem, so it is a table, and every pair was checked
against the implemented set rather than generated by a rule.
Even so: the first delegation table failed its own test because the
delegates are split across two crates, threads in the kernel and files
in the filesystem shim, and one crate was assumed to hold them all. The
knowledge entries were then rejected twice - found_by
claimed static when the database re-derives these as
published-standard, which is better
provenance than what was claimed, and the guard is what noticed.
Stated plainly: nothing calls them yet
The title that imports them reaches the vendor-named twins during boot and stops before the POSIX ones. Forty-nine declared, twenty-four served, zero reached in a run this project can currently do. That is the same posture as the pad shim: implemented ahead of demand because the names are confirmed and the behaviour needs no unmeasured structure. It is worth saying rather than letting a count of twenty-four imply something was unblocked.