sceAudio3dPortCreate checks its port id and reserved argument as shadPS4
does, then opens with a 0x10 parameter block. That block selects buffer
mode 0, which still throws, so no port is opened yet.
The 0x10 and 0x18 blocks of sceAudio3dPortOpen now take the defaults
shadPS4 and prosper fill in and go through the field checks before the
buffer mode throws.
sceAudio3dPortDestroy and sceAudio3dPortGetStatus get the signatures
from Orbital and SharpProspero and keep throwing; the debt entries of
the six remaining exports say what is still unknown.
ICU 78.1's u_unescapeAt dereferences the offset and calls the callback without checks, and u_unescape reads the source without one, so a null one faults: throw std::invalid_argument there instead of NotImplemented_nid_no_patch. A negative u_unescape capacity is clamped by _appendUChars and fails every room check, so nothing is written and the full length is returned; only a capacity whose signed difference with the output length overflows, which ICU leaves undefined, still throws.
jxrlib's readIS and writeIS use the bit state, the stream and its callbacks without checks, and pass a null packet to the read or write callback before dereferencing or offsetting it. Throw std::invalid_argument at those points instead of NotImplemented_nid_no_patch, and let a null packet reach the callback first, so a failed write of a null packet returns the callback's error as jxrlib does.
JSStringCreateWithUTF8CString and JSStringIsEqualToUTF8CString take a null
UTF-8 pointer as a null string, and JSStringCreateWithCharacters returns a
null string for null characters of any length, as WebKit's JSStringRef.cpp
and WTF's String constructors do. A length above WebKit's 2147483635-unit
limit and a null handle given to retain, release or the maximum-size query
throw std exceptions where JavaScriptCore crashes. The reference count is a
wrapping 32-bit counter and the maximum UTF-8 size is computed in 32 bits,
as in WTF.
The device test raced sceUsbdCancelTransfer on the first interrupt IN endpoint of the device. On Windows the first one can belong to a mouse or keyboard collection, which the system opens exclusively, so libusb's HID backend cannot read it and the submission failed, reported as a failed cancel race. The test now tries each interrupt IN endpoint, requires a refusal to be the host's I/O error with nothing in flight, and races on the first one the host accepts, with a buffer sized from that endpoint.
Keep a copy of the name with the semaphore and move the export from the libkernel_sys stub into libkernel next to the other sem_* exports.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
PS5_Vulkan measured on a base PS5 set to 1080p output that
sceVideoOutIsOutputSupported(15) answers 0, neither 1 nor an error, and
that sceVideoOutConfigureOutput(15) then returns 0x80290019, in a title
declaring high-frame-rate output. A host display below 120 Hz answered
0x80290016 to both instead. Titles that branch on the answer being 1
are unchanged; the undeclared-title answer stays 0x80290016.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
PS5_Vulkan measured on a PS5 (firmware 13.40) that
sceVideoOutRegisterBuffers2 refuses a set at buffers 15 to 19 with
0x80290001. The call threw instead. The other out-of-range arguments
keep throwing.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
fputws and wprintf write a UTF-16 surrogate pair as one four-byte
UTF-8 sequence, but fgetwc decoded that sequence into a single code
point above 0xFFFF, which is not a 16-bit guest wchar_t value, and
fgetws stored it truncated: fputws(u"A\U0001F600\n") read back as
A, U+F600, newline.
fgetwc now returns the high surrogate and keeps the low one in the
stream for the next read, so fgetws stores the pair, also when the
buffer fills between the two halves. A successful seek discards it,
as FreeBSD's fseeko resets the stream's mbstate. Sequences that
decode to an overlong form or above U+10FFFF, and lead bytes F8 to
FF, fail with EILSEQ instead of returning made-up characters; the
three-byte surrogates that fputwc writes for a single unit are still
read back as that unit.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01QegaHM5QeCynUQ2ZLWHE4b
A buffer V# whose TYPE is not 0 threw "buffer descriptor uses an
unsupported type" for every access. Measured on a PS5 (CFI-1115B,
firmware 12.20): through a V# with TYPE 2 or 3 and FORMAT 0 or a valid
format, buffer_store_dword and buffer_store_format_x write nothing and
don't fault, so a buffer a shader only stores to through one is bound as
a null V#. Loads and atomics through those V#s leave the destination VGPR
unchanged, which a null V# can't reproduce, so they still throw. Through
a TYPE 0, FORMAT 0 V#, vector loads return 0 and stores are dropped, and
those buffers are bound as a null V# too. TYPE 1 faults the GPU for every
access measured and keeps throwing.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Adrià