Blog exchange dissects how object pools change use-after-free bugs from type confusion to logical errors

A reply-post analyzing a reader's use-after-free bug in a limit-order matching engine argues that object pools change the nature of memory bugs rather than eliminating them. The author explains that without pooling, a freed-and-reused memory slot can let two different object types collide, potentially turning a stale pointer into a code-execution exploit via a mismatched function pointer. With pooling, the same logical use-after-free persists, but because the recycled memory always holds the same type, the dangerous type confusion is avoided—unless the object itself contains an inline tagged union, which reopens the original hazard.