feat(libc): implement memrchr

[LeandroLP23]

Carrying @MarcZX100's #1592, which was closed because no title stopped on memrchr yet. The change is theirs (8ac8c93a and 8e7a88d8, squashed onto current main with MarcZX100 kept as the author; the only conflict was the test registration in libc/CMakeLists.txt, resolved by keeping both blocks).

What

Implements memrchr (5G2ONUzRgjY) in libc: it scans the first n bytes backwards for (unsigned char)c and returns a pointer to the last match, or null, as in FreeBSD.

PICO-8 for PS5 (PPSA99808 v0.1.2, RafaelNGP/pico8-ps5, GPL-3.0) now stops on it at start-up on main (@screamm's run on #1578, and mine below):

FAIL: unresolved ELF import 5G2ONUzRgjY from libSceLibcInternal.prx

Tested

Windows 11, WinLibs GCC 15.2.0 r7, Release:

• PICO-8, relinked with the title's own libc.prx unwrapped: on main 5b4709f it stops at 5G2ONUzRgjY (memrchr); with this change it gets past it to FAIL: unresolved ELF import oxMp8uPqa+U from libkernel.prx (pthread_set_name_np, feat(libkernel): implement pthread_set_name_np #3031).
• guest_memrchr (last match, c above 255 truncated to a byte, a shorter n, no match) and guest_strings pass 3/3; the patched libc.prx exports 5G2ONUzRgjY; conventions and test registration pass.

Fork CI (run): Windows and the three relinker jobs pass. Linux fails agc_driver_image_packed16_load and agc_driver_flat_apertures (timeout) on lavapipe; an unrelated change on the same main (run) fails the same two, so they come from main, not from this change.

Checklist

• Based on current main; no other open PR implements the same functions
• One topic per PR; follow-ups go in a new PR
• No comments in code except technical debt
• Unimplemented paths throw (NotImplemented_nid_no_patch); silent stubs are listed in TechnicalDebt
• No notes, investigation .md files or images added to the repository (attach them to this PR)
• New third-party code is a submodule built from source
• Generic behaviour, not specific to one title
• Depends on: none
• AI-assisted: yes (Claude Code)

[github-actions]

Progress report (e8d6de4 → 890169e)

➖ System libraries: 85.62% (+0.0%, +1 implemented functions)

✅ 1 implemented

Library	Name
libc	memrchr_nid_postfix

[Dextroid17]

The closure and the reopening tell the whole story, and this is the right way to answer one: #1592 was closed because no title stopped on memrchr, and now PICO-8 does — with the exact FAIL: unresolved ELF import … line and two independent runs, one of them not the author's. That is the acceptance bar answered with evidence, and the second run is what makes it more than a claim.

The implementation is the canonical one, including the detail that usually goes wrong. Scanning backwards from n to zero and comparing through static_cast<unsigned char>(c) is both FreeBSD's behaviour and the only correct reading of the argument — a signed comparison is the classic bug in this family. Carrying MarcZX100's change with their authorship kept, and describing the one conflict (the test registration, resolved by keeping both blocks), is the rest of the job done properly.

The one thing the test should pin is the difference from memchr. Returning the last match is the entire point of this function, so a case where the byte appears more than once — with the answer being the later one — is the case that distinguishes the two, alongside a not-found case. If the new file already has both, nothing to do here.

Written with AI assistance.

[babyhuey]

Linux check, since the fork CI's Linux job failed on unrelated lavapipe timeouts: 890169e merged onto main 06da117 (clean), Ubuntu 24.04, GCC 13, Release. guest_memrchr passes 5/5 (--repeat until-fail:5). PICO-8 (PPSA99808) on Linux reports 802pFCwC9w0 (__udivti3, #545) before memrchr, on main and with this PR, so its memrchr stop only shows on Windows, as in your run.