Isn't reading an uninitialized variable that could have been given a "register" qualifier undefined behavior? That is, the program never takes the address of __.
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.
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:
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.
https://github.com/duckythescientist/obfuscatedLife/blob/mas...
Code is obfuscated more than needed to run. It starts with something simple like this:
"I abuse 2's complement math to initialize it as -1"
Instead of: __ = -1 The code reads: __=~__+__
... and then gets more and more bizarre.