* Fix drive_insert copying newname onto itself
DISK_hsync's delayed insert passes drv->newname as fname_in, so
_tcscpy(drv->newname, fname_in) copied a buffer onto itself: undefined,
and fatal under macOS's __strcpy_chk. Same guard as 3683392b (lost in
the 4.5.0 rebase) and WinUAE.
* Guard the drive_insert self-copy fix with __LIBRETRO__
* Fix save-state/rewind corruption for WHDLoad games loaded from archives
Restore proportional save-state buffer margin for filesystem overhead, fix
archive unit cleanup, and use archive-aware file restore paths instead of
unconditional host-path checks that fail for archive/CDFS-backed content.
* Wrap filesys.c fixes in __LIBRETRO__ guards for upstream compatibility
Per maintainer review, vendored upstream code changes require #ifdef
__LIBRETRO__ guards to ensure filesys.c behaves identically to upstream
when __LIBRETRO__ is undefined. Guarded changes include: close_filesys_unit
zarchive cleanup, restore_aino archive/CDFS existence checks, restore_key
archive/CDFS-aware fs_openfile fast path, and the pn native-path leak fix.
Also improves retro_load_game save-state size estimate to account for
mounted filesystem units and adds error logging to retro_serialize when
the buffer is too small.
---------
Co-authored-by: Pat9496 <[email protected]>
zlib is bundled now, so pointing -I at an external zlib tree is at best
redundant and at worst wrong:
- ps3/psl1ght: LIBUTILS is never defined, so ZLIB_DIR expanded to
'/zlib/'. Had it been set, it would have shadowed the bundled headers
the same way portlibs did on wiiu.
- emscripten: ZLIB_DIR is only assigned inside the ps3 branch, so the
flag expanded to a bare '-I', which silently swallowed the following
option as its argument.
No platform still needs an external zlib include path.
Since libz/7zip are compiled unconditionally, deps/libz/zutil.h's
<zlib.h> resolved to $(DEVKITPRO)/portlibs/ppc/include/zlib.h instead
of the bundled compat header, because the portlibs -I sits in CFLAGS
and CFLAGS precedes INCDIRS on the compile line.
That header declares adler32 as uLong(uLong, const Bytef*, uInt),
conflicting with our uint32_t(uint32_t, const uint8_t*, size_t):
deps/libz/adler32.c:49:10: error: conflicting types for 'adler32'
Put the compat zlib include ahead of the portlibs one.
zutil.h's legacy fdopen fallback collides with the system declaration
in recent Apple SDKs.
The issue is reported with Xcode 16.3 / Apple clang 17 / macOS 15.4
SDK and Xcode 16.4 / macOS 15.5 SDK, while Xcode 16.1 / Apple clang 16
is reported to work.
Guard the fallback on __APPLE__ so Apple builds use the system fdopen().
sonninnos