dr.p

Thanks

__________________
Neeley.org

grumpy

That's just the way it is in practice.

Laying out a program out in memory so it is possible to detect invalid memory accesses is expensive: results in a program that uses more memory, runs slower, etc, etc. Compiler/linker writers tend to be pressured by developers to produce "efficient" code so they normally do things by assuming code does not do memory overruns. Since the difference, performance wise, can be orders of magnitude, there is a lot of pressure on compiler writers to err on the side of performance at the cost of failing to detect all potential errors.

This means that the layout of variables (or structures or dynamically allocated memory) is not designed to detect overruns. Two unrelated variables A and B may be placed placed adjacent in memory because that happens to be the "optimal" way of laying things out. Code which does an overrun while working with variable A can therefore overwrite variable B, but this will not be detected. If some other code comes along and accesses variable B, it will do something unintended and (probably) write wrong data somewhere else. These things tend to bubble along, until some confused code tromps an area of critical memory -- at which point an invalid access is detected and an error reported (eg exception is thrown).

Products like Electric Fence work by laying out memory and other things so invalid memory accesses are more likely to be detected. In practice, they increase the odds of detecting invalid operations, but do not guarantee they will be detected.