Dynamic type of objects and aliasing
7.2.1 [basic.lval]
Gabriel Dos Reis

Created on 2007-05-23.00:00:00 last changed 36 months ago


Date: 2017-03-15.00:00:00

Proposed resolution (March, 2017):

This issue is resolved by the resolution of issue 1776.

Date: 2007-07-15.00:00:00

Notes from the July, 2007 meeting:

This is the same issue as C's DR236. The CWG expressed a desire to address the issue the same way C99 does. The issue also occurs in C++ when placement new is used to end the lifetime of one object and start the lifetime of a different object occupying the same storage.

Date: 2007-08-05.00:00:00

The aliasing rules given in 7.2.1 [basic.lval] paragraph 10 rely on the concept of “dynamic type.” The problem is that the dynamic type of an object often cannot be determined (or even sufficiently constrained) at the point at which an optimizer needs to be able to determine whether aliasing might occur or not. For example, consider the function

    void foo(int* p, double* q) {
        *p = 42;
        *q = 3.14;

An optimizer, on the basis of the existing aliasing rules, might decide that an int* and a double* cannot refer to the same object and reorder the assignments. This reordering, however, could result in undefined behavior if the function foo is called as follows:

   void goo() {
      union {
         int i; 
         double d;
      } t;

      t.i = 12;

      foo(&t.i, &t.d);

      cout << t.d << endl;

Here, the reference to t.d after the call to foo will be valid only if the assignments in foo are executed in the order in which they were written; otherwise, the union will contain an int object rather than a double.

One possibility would be to require that if such aliasing occurs, it be done only via member names and not via pointers.

Date User Action Args
2018-02-27 00:00:00adminsetmessages: + msg6153
2018-02-27 00:00:00adminsetstatus: drafting -> cd4
2007-08-05 00:00:00adminsetmessages: + msg1518
2007-08-05 00:00:00adminsetstatus: open -> drafting
2007-05-23 00:00:00admincreate