Joseph S. Myers wrote: > On Sun, 28 Jan 2007, James Dennett wrote: > >> Therefore, a case can be made that *for an implementation >> in which a type has no trap values*, an indeterminate >> value must correspond to some specific value. In other >> words: reading an uninitialized int is undefined behavior >> only if int includes trap representations in a given >> implementation. Otherwise, all we have is an unspecified >> (but valid) value, which is a common assumption. >> >> I'm not sure that I like this conclusion, but I've not >> seen a really good argument against it. > > DR#260 seems clear enough that indeterminate values may be treated > distinctly from determinate values including randomly changing at any > time. > > http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_260.htm
It does say that. (It also says some untenable/pointless things about tracking the origins of pointer values, which I'm sure when reduced to objective tests would amount to precisely nothing.) Looks like C99 was an aberration in how it defined indeterminate values, and that DR#260 (do you know if it's in TC1) says that we're back to how it used to be (and how it's expected to be in C++), which is that reading an indeterminate value (except via lvalues of character type) is undefined behavior. -- James
