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.
Chris Danford