RFR: 8145096: Undefined behaviour in HotSpot

[Kim Barrett]

On Dec 11, 2015, at 6:19 PM, Andrew Haley <aph at redhat.com> wrote:
> 
> On 11/12/15 19:33, Kim Barrett wrote:
>> pps. The union trick is undefined behavior because it reads a union
>> member other than the last one written. 
> 
> Hmm.  The members are certainly in the same memory locations, and I
> suspect that the language in 3.10 (Lvalues and rvalues) about signed
> and unsigned types allows it too.  But never mind: we only need one
> way to do this, and if we can agree that it works we're done.

I think we're all agreed that John's reinterpret_cast suggestion is
the way to go, but for the record, there happens to be a parallel
discussion of the union trick occurring on another mailing list I'm
on.  It's reported there that C11 allows the union trick.  Also
reported that discussion within the C++ committee has deemed it a bad
idea for C++, and that there exist compilers which generate "bogus"
code for the union trick, though no details were given.

Regarding generation of "bogus" code, consider this function:

int foo(int x) {
  union { int i; unsigned u; };
  u = x;
  return i;
}

The statement "u = x;" is a dead assignment.  Nowhere is u accessed
directly; nor is there a access of something that could alias u, since
there aren't any pointers/references taken.  The access of i doesn't
count, since accessing a union member other than the last one assigned
is UB.  Since the assignment is dead, the compiler may elide it.

Another way of looking at it is that i is nowhere assigned, making the
statement "return i;" problematic.  There is no connection between the
assignment of u and the access of i.  The compiler might choose any
value to return, including a trap-representation.