...
In the common case, on implementations that make use of a program stack, this value defaults to whichever values are currently stored in stack memory. While uninitialized memory often contains zeroeszeros, this is not guaranteed. On implementations that include trap representations, reading an uninitialized object of any type other than unsigned char (including int) may trigger a trap. Uninitialized memory has indeterminate value, which for objects of some types can be a trap representation. Reading uninitialized memory is undefined behavior (See undefined behavior 1210 of Annex J.) Consequently, uninitialized memory it can cause a program to behave in an unpredictable or unplanned unexpected manner, lead to undefined behavior and can provide an avenue for attack.
Additionally, memory allocated by functions, such as malloc(), should not be used before being initialized as its contents are also indeterminate.
In most cases, compilers warn about uninitialized variables, discussed in MSC00-C. Compile cleanly at high warning levels. In other cases, compilers will completely optimize out the uninitialized variables.
...
In this noncompliant code example, the process id, time of day, and uninitialized memory junk is used to seed a random number generator. This is characteristic of some distributions derived from Debian that utilized use uninitialized memory as a source of randomness. Although the unpredictable property of junk is desired, the problem here is that some compilers will actually optimize out the uninitialized variable completely, resulting in a loss of desired entropy.
...