which will stack allocate small (128 or less bytes) blocks and Malloc the
rest...naturally these now have to be paired with __PHYSFS_smallFree() calls,
so you can't be as lazy as a basic alloca() would let you be. The benefit is
both less malloc pressure for those temporary allocations and better stack
overflow safety (so if some jerk tries to push a 78 megabyte string through
the library as a filename, we won't try to strcpy it to the stack).
platform-specific stricmp implementations, changed appropriate calls to an
ASCII-only stricmp that ignores locale. Fixed case on UTF-8 API entry points.
To: icculus@clutteredmind.org
Subject: Bug in zip archiver
Date: Sat, 23 Jul 2005 22:19:09 +0200
Hi!
PhysFS has a bug in the ZIP archive module, function zip_find_start_of_dir.
Upon encountering a substring match, rc is set to a wrong value. The fix is
simple: swap both assignments like this:
[patch below --Ed.]
Some additional info for testing: Symptoms when you encounter this bug: A dir
is reported as empty although it has files in it; prerequisites or
encountering it: two dirs, one a substring of another, like "data/txt" and
"data/txt2", laid out in a way so that variable "middle" points to a file in
txt2 at some point during zip_find_start_of_dir
By the way, if you're interested in where PhysFS is used: I found this bug
while writing a patch for DOSBox (http://dosbox.sourceforge.net) to support
ZIP files. And I'd love to see that enhanced PHYSFS_mount syntax in an
official release soon *hint* ;);)
triggered massive tweaking in physfs.c. A lot of code got little
cleanups, which was nice. Less malloc pressure, too, since opening a
file used to allocate a ton of crap and mush it together...now it's
basically down to one structure and the instance data in whatever
archiver.
which simplifies things, removes some responsibility and code
duplication from the archivers, and trims some malloc pressure.
Also ripped up the allocation hook code a little. We'll try to screw
with memory locking later, since it makes everything ugly and
complex. Oh well.
"Meh. I just realized the wad archiver isn't considering ExMx or MAPxx entries
correctly, it treats them as files,when it should consider them directories,
and place the next 11 entries in that directory.Right now it's making it
impossible to open maps, since they all have the same names, they all overlap.
So it's not very useful right now.
...
Here's the patch to wad.c, it should now correctly place the map-files into
subdirectories."
Thanks, Travis!
Ryan C. Gordon
bhook