fix: stop cleanName truncating titles that contain a dot - #25
Closed
lepht wants to merge 3 commits into
Closed
Conversation
Adopted from upstream LoveRetro#722 by Eric Reinsmidt, taken while upstream is still GPL-3.0 (see LoveRetro#765). cleanName() ran removeExtension() over names the game time db already stores without one, so the first dot in a title was read as a suffix boundary. "Gun.Smoke" displayed as "Gun" and "Dr.Mario" as "Dr". Both callers in this tree - gametime.c and gametimedb.c - pass rom->name, which is stored extension-free, so dropping the removeExtension() call is safe for every caller we have. Covered in tests/test_utils.c: the two truncation cases fail without the fix, alongside guards for the behaviour that has to survive it - numeric sorting prefixes, underscores and region parens. Co-Authored-By: Eric Reinsmidt <eric@reinsmidt.com>
Closes #6. Adopted from upstream LoveRetro#723 by Eric Reinsmidt, taken while upstream is still GPL-3.0 (see LoveRetro#765). top->entries->items[top->selected] was loaded unconditionally in both the input and the render path, so an empty directory read an uninitialised pointer out of the capacity-8 allocation Array_new() never clears. The render path then ran assert(entry) over it, which is an abort in a debug build rather than a latent read. This is the fix #6 asked for: hoist the count check above the load in both paths instead of relying on the downstream total>0 guards. The L1/R1 alpha jump handlers get the same treatment, and the assert goes away. Every remaining read of entries->items[top->selected] in this file is now behind a count or total>0 check. Array_new() still leaves its capacity uninitialised - that is unchanged and now unreachable, not fixed. Upstream wrote this for the empty-root case (no roms, Tools hidden); it covers the ordinary empty Roms/ folder #6 describes by the same route. Co-Authored-By: Eric Reinsmidt <eric@reinsmidt.com>
Adopted from upstream LoveRetro#799 by Prashant Vaibhav, taken while upstream is still GPL-3.0 (see LoveRetro#765). Clears the last two boxes in #16. Both cores were pinned backwards to dodge upstream drift. That was a holding action; this is the real fix, so the pins move forwards instead. mgba: libretro/mgba deleted Makefile.libretro in 8940477 when its CI moved to cmake, and patches/mgba.patch existed only to add a platform block to that file. The patch is deleted and the same flags now go to cmake directly via mgba_MAKE, with mgba_CORE pointing at the build dir. Pinned to e31759b (2026-08-05), verified cmake-only, exposing BUILD_LIBRETRO / LIBMGBA_ONLY / LIBRETRO_STATIC and building target mgba_libretro. cmake is present in the toolchain image, which also ships an aarch64 cross toolchain file. fceumm: the rewritten patch targets the post-8ed0cb2 Makefile.libretro, so it cannot apply to the commit we pinned to avoid that change. Pinned to b5e3566, whose Makefile.libretro blob is the exact pre-image the patch was written against. Verified per #16's method - `git apply --check` at the new pin passes for both tg5040 and tg5050, and fails at the old pin, so patch and pin have to move together. Deviation from upstream: their mgba_MAKE ends `-- $(PROCS)`, but the shared rule in all/cores/makefile already appends $(PROCS), which expanded to `-- -j4 -j4`. Dropped ours, keeping the `--` so -j4 still reaches the native build tool rather than becoming a cmake flag. Not built for ARM here - no container runtime in this environment - so the cmake cross-compile itself is still unproven on our side. CI covers it. Co-Authored-By: Prashant Vaibhav <prashant@vaibhav.de>
lepht
force-pushed
the
claude/upstream-open-prs-r90hll
branch
from
August 12, 2026 04:14
2efb01e to
5f543f4
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adopted from upstream LoveRetro#722 by Eric Reinsmidt, taken while
upstream is still GPL-3.0 (see LoveRetro#765).
cleanName() ran removeExtension() over names the game time db already
stores without one, so the first dot in a title was read as a suffix
boundary. "Gun.Smoke" displayed as "Gun" and "Dr.Mario" as "Dr".
Both callers in this tree - gametime.c and gametimedb.c - pass rom->name,
which is stored extension-free, so dropping the removeExtension() call is
safe for every caller we have.
Covered in tests/test_utils.c: the two truncation cases fail without the
fix, alongside guards for the behaviour that has to survive it - numeric
sorting prefixes, underscores and region parens.
Co-Authored-By: Eric Reinsmidt eric@reinsmidt.com
Co-Authored-By: Claude Opus 5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_01BYJRgYX2ru5WMsZL7Zjjqv