> Paul Schlie wrote: >>> Brooks Moses wrote: >>> <http://gcc.gnu.org/ml/gcc/2007-01/msg01119.html> ... >>> Does that logic work for you? >> >> no, as although a variable's value may not have been previously defined >> within the context of a particular program, a variable's access semantics >> are orthogonal to what ever value may result from that variable's access; > > No; it's not just the value that is undefined; it's the > behavior of code attempting to use that value that is > undefined. Aborting the program is quite conforming if > your program uses "the value" of an uninitialized int, > for example. I write "the value" in quotes because the > variable does not *have* a value until one is assigned > to it. The fact that storage allocated for the variable > holds some bit pattern shouldn't be confused with that > variable having a value; so long as the variable has not > been given a value, the compiler might read it from > anywhere or nowhere, and has no obligation to be > consistent. I've seen no justification for any claim > that there is an obligation on the compiler to produce > consistent values in this situation; the C standard, on > the other hand, states quite clearly that code *cannot* > rely on any such thing.
please see: <http://gcc.gnu.org/ml/gcc/2007-01/msg01124.html> clearly clarifying uninitialized variables have an INITIAL value, and thereby regardless of that value, x ^= x is then correspondingly well defined as the language correspondingly clearly defines the semantics of the expression independently of it's variable argument values whether they may be apriority determinate or otherwise. your corresponding supporting standard citation to the contrary?
