UTF16_Type::next() assumed every surrogate came in a valid pair, so a lone
high surrogate swallowed the unit after it, and one right before the
terminator stepped over it and kept reading. It now returns INVALID and
consumes only the bad unit, which sceCccDecodeUTF16() already checks for.
ShiftJIS::next() returned 0xA0 and 0xFD-0xFF as single-byte characters.
Like 0x80, which it already rejected, they encode nothing (the PSP's JIS
to UCS table in pspautotests/tests/ccc/jis2ucs.bin has no entry for any of
them), so they're INVALID too.
Only sceCcc uses these decoders.
next() would read a truncated lead byte's "second byte" unconditionally,
even when that byte was actually the string's null terminator - leaving
index_ one past the terminator, so a subsequent end()/next() call read
one byte out of bounds. Now checks for the terminator before consuming
it, returning INVALID without advancing past it.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01L4QAoxV2KY7ek4PcZw3WvY
Also move colorutil.cpp/h
linking build fix experiment
Delete a bunch of unused CMakeLists.txt files
CMakeLists.txt linking fix
Don't include NativeApp.h from any headers.
Android.mk buildfix
Half of the UWP fix
Buildfix
Minor project file cleanup
Buildfixes
Guess what? More buildfixes!
mariobob