Date: Mon, 6 Jan 2014 11:46:11 -0800
On Mon, Jan 6, 2014 at 10:22 AM, Jason Merrill <jason_at_[hidden]> wrote:
> On 01/06/2014 04:26 AM, Fabio Fracassi wrote:
>> if it is not (legal): could we make it legal or would we run afoul of
>> the aliasing rules?
>
> The access is not allowed by the aliasing rules in 3.10. But it seems
> that this would be:
>
> struct B {
> int i;
> };
>
> struct D {
> B bmem;
> void foo() { /* access bmem.i */ }
> };
>
> B b;
> reinterpret_cast<D&>(b).foo();
>
> because B is a non-static data member of D, and 9.2/19 guarantees that
> the address of D::bmem is the same as the address of the D object.
The NaCl compiler broke code using this pattern, and we had to fix it
with https://codereview.chromium.org/10579030 and
https://codereview.chromium.org/11078014. We couldn't ever find a
clear place in the standard where it either allowed the pattern or
disallowed it, and I didn't get a chance to dig into the compiler to
figure out what transformation was breaking the code, so it's possible
it was a compiler bug instead of a code bug, but the pattern was
sketchy enough that we changed the code. 9.2/19 doesn't obviously
apply because no D object was ever created.
However, I don't think the above anecdote should prevent this group
from changing the rules to allow this use.
Jeffrey
> On 01/06/2014 04:26 AM, Fabio Fracassi wrote:
>> if it is not (legal): could we make it legal or would we run afoul of
>> the aliasing rules?
>
> The access is not allowed by the aliasing rules in 3.10. But it seems
> that this would be:
>
> struct B {
> int i;
> };
>
> struct D {
> B bmem;
> void foo() { /* access bmem.i */ }
> };
>
> B b;
> reinterpret_cast<D&>(b).foo();
>
> because B is a non-static data member of D, and 9.2/19 guarantees that
> the address of D::bmem is the same as the address of the D object.
The NaCl compiler broke code using this pattern, and we had to fix it
with https://codereview.chromium.org/10579030 and
https://codereview.chromium.org/11078014. We couldn't ever find a
clear place in the standard where it either allowed the pattern or
disallowed it, and I didn't get a chance to dig into the compiler to
figure out what transformation was breaking the code, so it's possible
it was a compiler bug instead of a code bug, but the pattern was
sketchy enough that we changed the code. 9.2/19 doesn't obviously
apply because no D object was ever created.
However, I don't think the above anecdote should prevent this group
from changing the rules to allow this use.
Jeffrey
Received on 2014-01-06 20:46:32