Created on1999-06-26.00:00:00 last changed145 months ago
[Moved to DR at the April, 2013 meeting.]
Proposed resolution (February, 2012):
This issue is resolved by the resolution ofissue 616.
Does the Standard require that an uninitialized auto variable havea stable (albeit indeterminate) value? That is, does the Standardrequire that the following function returntrue?
bool f() { unsigned char i; // not initialized unsigned char j = i; unsigned char k = i; return j == k; // true iff "i" is stable }6.9.2 [basic.fundamental] paragraph 1requires that uninitializedunsigned char variables have avalid value, so the initializations ofj andk arewell-formed and required not to trap. The question here is whetherthe value ofi is allowed to change between thoseinitializations.Mike Miller:6.10.1 [intro.execution] paragraph 10says,
An instance of each object with automatic storageduration (6.8.6.4 [basic.stc.auto]) isassociated with each entry intoits block. Such an object exists and retains itslast-stored value during the execution of the blockand while the block is suspended...I think that the most reasonable way to read this is that theonly thing that is allowed to change the value of an automatic(non-volatile?) value is a "store" operation in the abstractmachine. There are no "store" operations toi between theinitializations ofj andk, so it must retain itsoriginal (indeterminate but valid) value, and the result ofthe program is well-defined.
The quibble, of course, is whether the wording "last-storedvalue" should be applied to a "never-stored" value. Ithink so, but others might differ.
Tom Plum:9.2.9.2 [dcl.type.cv] paragraph 8says,
[Note:volatile is a hint to the implementationto avoid aggressiveoptimization involvingthe object because the value of the object might be changed by meansundetectableby an implementation. See6.10.1 [intro.execution] for detailedsemantics. In general, the semanticsofvolatileare intended to be the same in C++ as they are in C. ]>From this I would infer that non-volatile means "shall not bechangedby means undetectable by an implementation"; that the compiler is entitled tosafely cache accesses to non-volatile objects if it can prove that no"detectable"means can modify them; and that therefore ishallmaintain the same valueduring the example above.
Nathan Myers:This also has practical code-generation consequences. If theuninitialized auto variable lives in a register, and its value isreally unspecified, then until it is initialized that registercan be used as a temporary. Each time it's "looked at" the variablehas the value that last washed up in that register. After it'sinitialized it's "live" and cannot be used as a temporary any more,and your register pressure goes up a notch. Fixing the uninit'dvalue would make it "live" the first time it is (or might be) lookedat, instead.
Mike Ball:I agree with this. I also believe that it was certainly nevermy intent that an uninitialized variable be stable, and I wouldhave strongly argued against such a provision. Nathan has wellstated the case.And I am quite certain that it would be disastrous for optimizers.To ensure it, the frontend would have to generate an initializer,because optimizers track not only the lifetimes of variables, butthe lifetimes of values assigned to those variables. This wouldput C++ at a significant performance disadvantage compared toother languages. Not even Java went this route. Guaranteeingdefined behavior for a very special case of a generally undefinedoperation seems unnecessary.
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2014-03-03 00:00:00 | admin | set | status: drwp -> cd3 |
| 2013-10-14 00:00:00 | admin | set | status: dr -> drwp |
| 2013-05-03 00:00:00 | admin | set | messages: +msg4366 |
| 2013-05-03 00:00:00 | admin | set | status: ready -> dr |
| 2012-02-27 00:00:00 | admin | set | status: review -> ready |
| 2011-09-06 00:00:00 | admin | set | messages: +msg3497 |
| 2011-09-06 00:00:00 | admin | set | status: open -> review |
| 1999-06-26 00:00:00 | admin | create | |