[physfs] adding archive paths to search paths

Ryan C. Gordon icculus at clutteredmind.org
Sun Dec 1 06:42:04 EST 2002


> On a semi-related note, is it possible to access an
> archive embedded in another archive? So far I have not
> had any success with this.

There isn't any way to do so at this time, I'm afraid.

> Finally, I had two questions about writing. First, is
> it possible to write a compressed file? I would like
> to compress my save game files.

The architecture of the library allows for it, but none of the archivers
have code to do so, since it would be awkward to do well. Basically,
there's an "openWrite" method in the archivers, all of which (except the
native filesystem driver) are stubs that return errors.

There's no reason this can't be filled in, but it'd be a pain, since you'd
pretty much have to buffer the file being written entirely to memory, then
rebuild the archive taking the new file into account (which can be an
expensive operation depending on the file format, number of contained
files, and compression level).

> Second, I have a bunch of utilities that rely on
> fprintf. Since PhysFS file handles don't seem to be
> compatible with standard file handles, is there a good
> workaround I can try?

The cheap trick is to do something like this:

#define _GNU_SOURCE
#include <stdio.h>
#include <stdarg.h>

int physfs_printf(PHYSFS_file *f, const char *fmt, ...)
{
    static char buf[2048];  // hope you never overflow this.
    int rc;
    va_list args;
    va_start(args, fmt);

    rc = vsnprintf(buf, sizeof (buf), fmt, args);
    va_end(args);

    return(PHYSFS_write(f, buf, rc, 1));  // should check retval.
}


...but a better solution (that is, one that actually parses a printf()
format string itself) would be more portable and more robust. The above
will probably be 99% effective, though.

--ryan.





More information about the physfs mailing list