Samofatov, Nickolay wrote:
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:
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.
/* Ignore the request if the database or lock block does
to be valid . */
if ((MemoryPool::blk_type(dbb) != type_dbb) ||
!(lock = dbb->dbb_lock) ||
(MemoryPool::blk_type(lock) != type_lck) || !(lock->lck_id))
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
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.