I strong advise that the following be applied to Firebird 2.0.

In alloc.h, class Firebird::MemoryPool:

    /// Returns the type associated with the allocated memory.
    static SSHORT blk_type(const blk* mem) {
        return ((MemoryBlock*)((char *)mem - MEM_ALIGN(sizeof(MemoryBlock))))->type;
    /// Returns the pool the memory was allocated from.
    static MemoryPool* blk_pool(const blk* mem) {
        return ((MemoryBlock*)((char *)mem - MEM_ALIGN(sizeof(MemoryBlock))))->pool;

This means an object not inheriting from blk will force a compilation error.  This requires that the line
struct blk;
be included before the "namespace Firebird" in alloc.h.

In fb_blk.h:
struct blk
    virtual void doesNothing() {};
This forces "blk" to be a virtual class.  The implicit type conversion from a virtual subclass to a non-virtual superclass changes the pointer on at MSVC to skip over the virtual function vector pointer.

It is also necessary to change any class that has blk_type or blk_pool references from a declaration like
class Database : pool_alloc<type_dbb>
class Database : public pool_alloc<type_dbb>
so "blk" is accessible.

This doesn't fix the problem, but it will cause a compiler exception in aggregious cases.   The proper fix is to move "blk_type" and "blk_pool" back into "blk" where they belong, then hunt down and fix the cases where implicit assumptions have been made about memory manager implementation.

Jim Starkey
Netfrastructure, Inc.
978 526-1376