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).
(transplanted from 8b3cc36531c6ac09dbac98d3774921bdf14b240d)
Regardless of what the 3.0.0 documentation says, PhysicsFS never handled this
correctly, so now we check for it so you can't get into crashy situations.
Corrected documentation to reflect reality.
(transplanted from 0bbfaf6c5508139ba3d417377c94d75ca921772a)
So if a zip file goes to the zip archiver but is corrupted, the system can now
know not to bother trying other archivers once the zip archiver has had a shot
at it, and just as important: it can report the real error from that archiver
instead of a generic "unsupported."
Now callbacks can stop further enumeration and report errors, if they had a
catastrophic issue or just found what they needed and don't need to process
any more items.
Also, the actual enumerators can report errors instead of silently dropping
items. This led to several other fixes as all these implementations got
audited and reworked.
The original, non-callback enumerator now returns NULL if it can't produce a
complete list instead of dropping items and returning a partial list.
- Dramatically reduce RAM usage: uses between 8 and 11 kilobytes less static
memory for its internal case-folding tables.
- Actually works now. It would fail unconditionally if a codepoint folded
into multiple codepoints, even if the compared string contained those exact
codepoints.
- Now a public API!
- Removed __PHYSFS_utf8strnicmp(): nothing was using it, it was incorrect
anyhow, and what does 'n' represent when either string might case-fold to
something larger in-flight, anyhow?