'Simple' stack problem

Dombo wrote:

> That doesn't necessarily have to the case. Sometimes faulty code works 
> correctly and may pass unit tests without a hitch. In that case the 
> effects of the faulty code may only exhibits itself after something (OS, 
> compiler, compiler settings, seemingly unrelated code, new library 
> version...etc) has changed.

In shorter words: no amount of dynamic testing can ever prove a system 
to be bug-free.

Some will even go as far as to state "testing proves diddly-squat!", but 
that's a bit too strong --- testing can still prove errors, after all. 
It just can't prove correctness.

> Recently we had code that ran fine on Linux and passed all unit
> tests, but a debug build of the same code crashed on Windows. It
> turned out that a pointer was still being used after freed. On Linux
> the free operation left the contents of the freed memory intact. With
> the Windows debug library free operation overwrites the freed memory
> with a certain pattern, so the bug became visible.

Lesson learned: do all your unit-test runs in valgrind!