> Richard Guenther wrote: > On 1/27/07, Paul Schlie <[EMAIL PROTECTED]> wrote: >>>> On Fri, Jan 26, 2007 at 06:57:43PM -0500, Paul Schlie wrote: >>> Likewise, if the program has an uninitialized variable, the behavior >>> will differ depending on details of optimization and how variables are >>> assigned to memory. Heap allocated for the first time might always be >>> zero (as the OS delivers it that way), turning on optimization might then >>> result in a nonzero initial value because of reuse of a register. >> >> - I would argue that in this circumstance although the resulting value may >> differ, the results are actually equivalent; as in both circumstances the >> value returned is the value associated with it's storage location; and as >> the value of all storage locations are arbitrary unless otherwise well >> specified; the result may change from run to run regardless of any applied >> optimizations. > > If you read from an uninitialized variable twice you might as well get > a different result each time. This is exactly the same issue than with > signed overflow and observable behavior - though as somebody notes > later - the uninitialized variable case doesn't stir up too many peoples > mind.
- However x ^= x :: 0 for example is well defined because absent any intervening assignments, all reference to x must semantically yield the same value, regardless of what that value may be. (but does not require that its associated storage location be literally referenced multiple times unless correspondingly declared as being volatile; as in effect variables declared as being volatile have no guarantee of retaining the value most recently logically assigned within a single tread of execution, and thereby in effect are bound to a storage location known to perpetually yield indeterminate values upon each distinct logically specified reference, but even here the semantics of the language requires that the reference be literally performed, and not assumed to yield any value although the value is undefined).