On 29/05/2020 07:14, Dmitry Vyukov wrote: >> (In C99 it gets subtler because an 'indeterminate value' is >> defined to be 'either a valid value or a trap representation', >> so arguably the compiler can only do this stuff if it _has_ >> trap representations for the type in question.) > Interesting. Are you sure that's the meaning of 'indeterminate value'? > My latest copy of the standard says: > > 3.19.2 > 1 indeterminate value > either an unspecified value or a trap representation Yes, but (from N1256): | 3.17.3 | unspecified value | valid value of the relevant type where this International Standard | imposes no requirements on which value is chosen in any instance | NOTE An unspecified value cannot be a trap representation
> My reading of this would be that this only prevents things from > exploding in all possible random ways (like formatting drive). The > effects are only reduced to either getting a random value, or a trap > on access to the value. Both of these do not seem to be acceptable for > a bpf program. A random value, XORed with itself, produces 0, which is what we want. (XORing a trap representation with itself, of course, produces a trap.) So it'd be fine *unless* the 'in any instance' language can be read as allowing the uninitialised object to have *different* random values on separate accesses. -ed
