Differences between gcc3 and gcc4 regarding uninitialized variables

We have a body of C++ code which is being ported from a RHEL4-based distro to RHEL-5-based. It used to compile with g++ 3.4.3, and now compiles with g++ 4.1.2. It turns out that there are local POD variables that are being used uninitialized, which is causing failures under the new environment -- not surprising, since C++ rules say that local POD structures are left uninitialized and therefore random.

I'm looking for an explanation of why this did开发者_C百科n't bother us when compiled with 3.4.3, but is now wreaking havoc with 4.1.2. Is there maybe an obscure setting in the specs of gcc3 that helpfully initialized local POD variables?

Undefined behavior is, as the name implies, undefined. The compilers don't have to explain why they do what they do, they don't have to do one thing consistently, and they don't have to have a reason for what they do.

The way compilers typically treat undefined behavior is to ignore it. There was never a GCC developer who sat down and said "let's write some code for how GCC handles uninitialized variables". Whatever happens to them happens as a result of falling through all the other code in GCC. So new versions of the compiler might do different things with uninitialized variables, not because the compiler handles them differently, but because it never intentionally handled them at all.

Perhaps by compiling your code with a more recent version (e.g. 4.6.1) of g++ and by asking for all warnings (using -Wall -Wextra), then by hacking the source code till no more warnings are issued, you could improve the situation