Try to look for the new name in the process's namespace before falling back
to the old one (and giving up on CD-ROM detection if everything falls apart).
iOS has PHYSFS_NO_CDROM_SUPPORT defined, so this isn't used there.
In file included from /home/runner/work/physfs/physfs/src/physfs.c:12:
/home/runner/work/physfs/physfs/src/physfs.c: In function ‘openDirectory’:
/home/runner/work/physfs/physfs/src/physfs.c:929:40: warning: ?: using integer constants in boolean context [-Wint-in-bool-context]
929 | BAIL_IF(!retval, claimed ? errcode : PHYSFS_ERR_UNSUPPORTED, NULL);
| ~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~
/home/runner/work/physfs/physfs/src/physfs_internal.h:273:44: note: in definition of macro ‘BAIL_IF’
273 | #define BAIL_IF(c, e, r) do { if (c) { if (e) PHYSFS_setErrorCode(e); return r; } } while (0)
| ^
Closes https://github.com/icculus/physfs/issues/44
If you edit a zip file with Windows Explorer, it will rewrite the entire
central directory, setting all files version_needed field to 2.0/MS-DOS,
but it won't touch files that it doesn't plan to alter, so you might end
up with a local header that doesn't match the central directory details.
We aren't currently using the version_needed information, so now we just
favor the local header's copy of it in case we ever need it, and don't
complain if the central directory doesn't match.
Fixes#24.
This compiled and worked on Android before, if you didn't care about
PHYSFS_getBaseDir() and PHYSFS_getPrefDir() being useful. Now you can pass
PHYSFS_init() some necessary Android objects to solve this. Passing NULL
to PHYSFS_init is acceptable and will simply report "/" for the base dir and
prefdir, under the assumption that the app queried the OS for these directly
instead.
This was clearly copied from a previous line but wasn't updated with the
correct condition to check, so if malloc() failed, it would dereference NULL
instead of reporting an error.
The former is meant to send PhysicsFS-buffered data to the PHYSFS_Io's
implementation, the latter is meant to tell the OS to definitely make sure the
data is safely written to disk (or at least, that's what it does in practice).
This was making PHYSFS_setBuffer()'d handles _slower_, since they would end
up blocking whenever the buffer was full until the data made the full trip to
physical media, instead of just letting the OS do its own buffering.
Now we still PHYSFS_Io::flush() on PHYSFS_close(), like this has always
worked. That might also be overkill, but that remains a historical artifact
of trying to keep the underlying file handle usable if pending writes fail
for possibly-recoverable reasons (which isn't guaranteed if you just close()
it, at least as far as I remember).
This way, if someone builds the default branch instead of stable-3.0, we'll
be able to distinguish.
No immediate plans for a format 3.1 effort at the moment, though.
Ryan C. Gordon
Ozkan Sezer
past-due
alfadur
Matthew Albrecht