this makes handling the relative "root" directory not a special case (".").
mountpoints now always begin with a slash. before, "/foo" and "foo" were
in two separate namespaces, which was weird and confusing; the two now
mean the same thing. there are no more special "default mountpoints"; just
mount to "/". "@path" mounts are now "/@path", and they do show up in
GetDirListing("/") (but, as before, opening "/@foo/bar" will never create
a "@foo/bar" path in a non-"@foo" mountpoint)
Common file interface class, RageBasicFile, shared by RageFile
and RageFileObj. This makes most uses of these objects interchangeable.
RageFile is now just a simple wrapper for RageFileObj, to create
files in FILEMAN's namespace; file objects can also be created
independently. This means that, for example, IniFile can be used
to write a file to a CString, without having to jump through hoops,
and without having to use a separate file access wrapper; just do
something like:
RageFileObjMem string_file;
ini.WriteFile( string );
const CString &sString = string_file.GetString();
object to a just-initialized state. deflateEnd() is correct (no comment
needed for that; it's obvious, I don't know why I used deflateReset to
begin with).
zlib doesn't appear to do anything special with allocations; running
the following:
#include <zlib.h>
main()
{
z_stream z; z.zalloc = NULL; z.zfree = NULL;
inflateInit2( &z, -MAX_WBITS ); inflateReset( &z );
}
under Valgrind shows:
==17033== 7080 bytes in 1 blocks are possibly lost in loss record 1 of 1
==17033== at 0x1B904EDD: malloc (vg_replace_malloc.c:131)
==17033== by 0x1B91D4B4: zcalloc (in /usr/lib/libz.so.1.2.1.2)
==17033== by 0x1B91D608: inflateInit2_ (in /usr/lib/libz.so.1.2.1.2)
==17033== by 0x80485A4: main (in /home/glenn/a.out)
The reason that only some people were experiencing a major memory leak
was that it had to do with packages, a lot of devs don't use packages.
This leak could not be found through conventional methods, as zlib's ram
seems to be allocated from the global ram.
The conventions I'm using are to put the entire copyright notice at the bottom
of each file, and to put the summary of the source file's use at the top of the
header.
Putting the license text in each file avoids confusion, and is normal practice
for many projects. Putting it at the bottom gets it out of the way; it's a
ton of clutter to put at the top.
The description is in the header. People who don't know what a class is for,
or how to use it, are probably looking at the header to see the interface,
not the implementation, so let's put the description in there. Keep it brief
(one line); any substantial implementation notes should go in the source file.
Chris Danford