Re: Self-XORing BPF registers is undefined behavior

On Fri, May 29, 2020 at 10:46 AM Edward Cree [off-list ref] wrote:

On 29/05/2020 07:14, Dmitry Vyukov wrote:

quoted

quoted

(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

quoted

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.

Ah, I see. I thought the result of such XOR is redefined to be an
indeterminate value rather than UB.
Thanks