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

If I output and/or work with uninitialized 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?
Cœur
  • 37,241
  • 25
  • 195
  • 267
Hardware Problem
  • 21
  • 1
  • Aren't there security conscious OSes that initialize all initialize memory so that you don't get to see what was left there by another process or another user? – Paul Tomblin Apr 17 '10 at 19:26
  • Garbage, yes, but esp. for stack variables more dangerous than just "random". Since the value is determined by previous execution path, you end up with really weird bugs. – peterchen Apr 17 '10 at 21:10
  • @Paul: If the OS behaves that way, you still end up with garbage. Its just not garbage that has anything to do with other processes/users. – Dennis Zickefoose Apr 17 '10 at 23:38

5 Answers5

11

"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.).

Baum mit Augen
  • 49,044
  • 25
  • 144
  • 182
Alex Martelli
  • 854,459
  • 170
  • 1,222
  • 1,395
5

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
  • 496,577
  • 130
  • 894
  • 1,212
  • 1
    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 Apr 17 '10 at 21:10
  • 5
    @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 Apr 17 '10 at 21:41
  • How would it segfault. I am having a hard time believing that part. – Tim Apr 17 '10 at 22:17
  • 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 Apr 17 '10 at 22:25
  • 2
    @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 Apr 17 '10 at 22:49
  • @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 Apr 18 '10 at 02:12
4

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.

GManNickG
  • 494,350
  • 52
  • 494
  • 543
  • 3
    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 Apr 17 '10 at 20:58
2

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
  • 5,065
  • 23
  • 24
2

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
  • 21
  • 1