What is a garbage value?

int a[100] {0} ;

a[100], a[-1], etc... will all produce "garbage values". Firstly, why does the "garbage value" spit out inconsistent values? What exactly is it?
The statement int a[100] {0} ; reserves a block of memory that is large enough to store exactly 100 integers and initializes each of those integers to have value 0.

a[100] is just after the end of that block. We know absolutely nothing about that area of memory.
a[-1] is just before the beginning of that block. We know absolutely nothing about that area of memory.

It is quite likely that those parts of memory are used for something, but there is no quarantee that they store integers. Even if they would contain integers, how could we possibly know for which variables the compiler has reserved those memory areas?


You could ask what is the color of grass on the planet Proxima b. Nobody has been there, nor knows whether there is grass at all. However, if you do ask for a color, our answers have to be names of colors. Those answers are free to be inconsistent, garbage, undefined behaviour.
to put it another way, memory is this big array that is used by all the programs on the system, including the OS etc. A program might start up, allocate memory, use it, do things, and exit. The memory it used is unchanged after that, keeping the old values. Then your program starts, and grabs memory that happens to be left over from that program. You get that value, and it could be anything.

You can exploit this on some OS some of the time ... I had one of those draw the fractal assignments and I drew each piece colored by uninitialized values. The recursive calls moved the stack and therefore the values' addresses around, such that at a given recursive level the color was the same for all at that level... it was a striking result. Being able to use them is rare, though... most of the time they are not safe to use for anything.

I also heard that in some situations it will cause your program to crash. Now why would it do that?
The operating system can crash your program if it catches it doing something it shouldn't do, such as writing to or reading from memory it doesn't own.
But note that your program is not guaranteed to crash even it does misuse arrays and pointers. That is to say, a program that crashes definitely contains an error, but some programs with errors may not crash, or may not crash immediately.
You have a wallet. You put cash into it. A lot. Later you open your wallet, but it has no cash in it!!!

Some thief has, unbeknownst to you, slipped in and relieved you of your burden. Would you crash due to loss of cash? So does a program.


If you do write to a[-1], then you are the thief that messes up the content of that memory location. Out of range error. Undefined behaviour.
> int a[100] {0} ;
> a[100], a[-1], etc... will all produce "garbage values".

Attempting to access a[-1] etc., as cppreference.com puts it succinctly and accurately,
"renders the entire program meaningless". http://en.cppreference.com/w/cpp/language/ub

In particular, after undefined behaviour has been engendered, there is no guarantee that a[1] or a[55] would not yield "garbage values"; there is no guarantee that 1+3 would yield 4 etc.: all bets are off. It is the entire program that has undefined behaviour; its implications are much more than just: "evaluating the expression a[-1] would yield some unpredictable result or may crash the program".

If it happens to be your lucky day, the program may crash immediately.
Topic archived. No new replies allowed.