The Memory Manager

Before we get started, we should cover ferite's internal memory manager. Under normal operation ferite uses it's own memory manager, which is basically a sub allocator, to achieve some significant performance gains over the s tandard malloc/free operations. This memory manager is used throughout ferite, and the data that is passed around in ferite is expected to be allocated under this manager. Using malloc to allocate memory for ferite internals will cause unexpected results. This is not to say that you cannot use malloc/free at all. That is not the case. Just don't use malloc/free for anything that you give to, or get from, ferite.

This new memory manager acts much like malloc/free in terms of how you use it. There are functions that mirror the malloc, calloc, realloc, and free calls.

• fmalloc( size )

• fcalloc( size, blocksize )

• frealloc( ptr, size )

• ffree( ptr )

These functions all look like and act like the functions they replace as far as the casual programmer is concerned. However, they smell different as far as the compiler is concerned, so don't mix calls on memory segments between malloc/free and fmalloc/ffree. They play well in the same sand-box, but don't ask them to swap tonka trucks with each other.

Unfortunately this means that there are only limited equivalents to the standard C functions that perform allocations such as strdup. More are likely to be implemented as time progresses, you can find the current available functions in the C apo. You can still use standard C library functions that don't attempt to free the memory you pass to them. So you're safe with printf. Basically, just keep track of who made gave you the memory, so you can give it back to the right one when you're done.