views:

156

answers:

5
int myInt;
cout << myInt; // Garbage like 429948, etc

If I output and/or work with unitialized variables in C++, what are their assumed values?

  • Actual values in the memory from the "last user"?

e.g.: Program A is closed, it had an int with the value 1234 at 0x1234 -> I run my program, myInt gets the address 0x1234, I output it like above -> 1234

  • Is it just random garbage?
+4  A: 

Its value is indeterminate. (§8.5/9)

There's no use trying to get meaningful data from it. In practice, it's just whatever happened to be there.

Most compilers will pack "meaningful" debug data in there in a debug build. For example, MSVC will initialize things to 0xCCCCCCCC. This is removed in an optimized build, of course.

GMan
0xCCCCCCCC is interesting because in x86, 0xCC is the debug interrupt (int3) instruction. Hence, if somehow the program tried to execute instructions from the unitialized memory (say due to a buffer overrun or some other such bug), it would immediately break into a debugger, permit a debugger to be attached, dump core, or some other similar OS-dependent function.
Adam Rosenfield
+11  A: 

"Random garbage" but with emphasis on "garbage", not on "random" -- i.e., absolutely arbitrary garbage without even any guarantee of "randomness" -- the compiler and runtime systems are allowed to have absolutely anything there (some systems may always give zeros, other might give arbitrary different values, etc, etc).

Alex Martelli
arbitrary garbage is definitely a better description
jk
+2  A: 

the integer is a variable on the stack since it is a local variable. As long as it has not been initialized, the data on the stack is as-is. It is (part of) a previously used data. So it is garbage, but it is not random since given the executable and a begin state, the value is predictable. Predicting is hard since you have to take into the account the OS, the compiler, etc and moreover it is very pointless.

Henri
+4  A: 

It's not even guaranteed to be a value at all. Trying to read the int, anything can happen (such as a signal sent causing your program to terminate). With particular importance in real life programming, switching on a not initialized bool can cause you hit neither true nor false cases.

Johannes Schaub - litb
I'm not sure the first part of that is true. Certainly the value of the int is indeterminate, but it has a well-defined location on the stack that the program can legally access, so I can't see any circumstance in which accessing it is undefined behavior.
Tyler McHenry
@Tyler the standard say it's undefined behavior if it's not initialized (see 4.1/1). It may contain any bit pattern whatsoever, including a trap representation.
Johannes Schaub - litb
How would it segfault. I am having a hard time believing that part.
Tim
Undefined behavior can, in theory, cause literally anything to happen. So if litb is right that it is UB, it could segfault. However, I'm having trouble finding where in the C++ standard it says that this is UB. 4.1.1 talks about UB for converting uninitialized *objects* into rvalues, but it doesn't seem to apply to fundamental types, and 3.9.6 confirms what he said about bools, but doesn't apply to ints.
Tyler McHenry
@Tyler why does it not apply to fundamental types? Also, 3.9.1/6 does not confirm what i say. It's a non-normative foot-note only. 4.1/1 is what confirms what i said. @Tim, anything can happen when you have undefined behavior. If the int contains a certain bit-pattern, and that pattern when read is defined as invalid (not mapped to an integer value), the operation system can kill your program. There *are* systems out there that have such patterns, called "trap representations". Read this: http://blogs.msdn.com/oldnewthing/archive/2004/01/19/60162.aspx . Please explain your downvote.
Johannes Schaub - litb
@litb You're correct. On re-reading, 3.9.1/6 does say it is UB. The words immediately before the part about being uninitialized that refer to "not being derived from `T`" had me thinking only in the context of class types. Also, I didn't downvote you; In fact I'm upvoting this now that you've helped me find where the C++ standard backs it up. Thanks. :)
Tyler McHenry
@Tyler, thanks mate :)
Johannes Schaub - litb
+2  A: 

Program A is closed, it had an int with the value 1234 at 0x1234 -> I run my program, myInt gets the address 0x1234...

Note also that because of virtual memory in modern operating system what Program A called address 0x1234 is unlikely to actually refer to the same space in physical memory as what your program calls address 0x1234.

Carl Gibbs