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();
often simpler than seeking; that some drivers may only support rewinding;
and that, if supported, rewinding should never fail. However, there's really
no reason for it to be a separate API call.
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.
didn't make it work, since there was no cast overload to bool&, etc; it
just forced the (non-POD) type to that type, which resulted in the struct
being clobbered.
Glenn Maynard