Samofatov, Nickolay wrote:
Object type in memory block header is needed only for memory usage
debugging and monitoring purposes. No code should ever branch on type of
memory block since such code it is usually a security hole.
There are, in fact, 38 references to "MemoryPool::blk_type" scattered around the engine.  This count doesn't include references buried in macros.  The following example from cch.cpp is typical, and is NOT condtional on development build:

/* Ignore the request if the database or lock block does not appear
   to be valid . */
    LCK lock;
    if ((MemoryPool::blk_type(dbb) != type_dbb) ||
        !(lock = dbb->dbb_lock) ||
        (MemoryPool::blk_type(lock) != type_lck) || !(lock->lck_id))
        return 0;

Note that this doesn't does throw an exception if the block appears incorrect, it just turns into a no-op.  Also note that since the Vulcan database object isn't allocated by your memory allocator, so this code utterly screws up everything.  This pattern is repeated an unknown number of times with unknown consequences.

This code is called as a lock manager AST.  Nobody checks the return.  If ever used in multiuser mode this would deadlock the system, first time, everytime.

This is unacceptable crap.  You have rendered a once reliable code base unsuitable for further development.  You apparently have no idea of the consequences of this example of incredibly poor technical judgement. 

If this is your idea of proper C++, there is no hope for Firebird 2.0.


Jim Starkey
Netfrastructure, Inc.
978 526-1376