In most cases, a program would just read from "dirty" memory and you might get a random value. In this case, whatever bits are there, they "add up" to -1, so it just works.

Yes, it is undefined behavior by the standard, but most compilers will give you some random value and you will get the answer that GhotiFish states.

lets say __ is 0x00101101

then it's ~__+__

so

   0x00101101
  +0x11010010

You can see how that always works.

Unfortunately not. When you have not written to a C variable, it doesn't have a random value, reading it is undefined. Different reads can produce different values.

Not really. When you declare a variable the system assigns it an address on stack. When you try to read it, it reads the value currently stored at that address. Subsequent reads all read from the same address.

Unless you have something else writing to this address, the value will not change. Since the program's stack is only available to that program, it will stay the same.

Yes, really. I don't think you understand the leeway that C/C++ give implementations when they encounter undefined behavior. Your mental model of how the code "should" be compiled can go out the window when an optimizer designed to work properly only on well-defined code goes to work:

http://blog.llvm.org/2011/05/what-every-c-programmer-should-...

I'm sorry, but nothing in that article contradicts what I wrote. I wrote that once variable is declared, a memory location is assigned to it and this location nor it's content change over time, unless you write to (initialize) it yourself.

Care to quote the sentence(s) that say differently?

as you said, reading it is just undefined. the compiler has to do something, and it's improbable that a read before write, followed by another read will result in two different values.

if you could produce a piece of code that exhibits the behaviour you describe, i'd very much like to see it.