Movatterモバイル変換

This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 119a. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.

2025-12-20

2828. Ambiguous interpretation of C-style cast

[Accepted as a DR at the March, 2024 meeting.]

(From editorial issue5355.)

Consider:

   int*** ptr = 0;   auto t = (int const*const*const*)ptr;

There is more than one way how this can be interpreted asastatic_cast followed by aconst_cast, namely:

  const_cast<int const * const * const * >(static_cast<int * * const * >(ptr));  const_cast<int const * const * const * >(static_cast<int * const * const * >(ptr));

Subclause 7.6.3 [expr.cast] paragraph 4 makes such a program ill-formed:

... If a conversion can be interpreted in more than one way as astatic_cast followed by aconst_cast, the conversionis ill-formed.

Proposed resolution (approved by CWG 2024-03-20):

Change in 7.6.3 [expr.cast] paragraph 4 as follows:

... If a conversion can be interpreted in more than one of the ways listedabove, the interpretation that appears first in the list is used, evenif a cast resulting from that interpretation is ill-formed. If aconversion can be interpreted in more than one way asastatic_cast followed by aconst_castisused and the conversion can be interpreted in more than one way assuch, the conversion is ill-formed.[ Example 1 :

  struct A { };  struct I1 : A { };  struct I2 : A { };  struct D : I1, I2 { };  A* foo( D* p ) {    return (A*)( p );  // ill-formed static_cast interpretation  }  int*** ptr = 0;  auto t = (int const*const*const*)ptr;  // OK,const_cast interpretation  struct S {    operator const int*();    operator volatile int*();  };  int *p = (int*)S();  // error: two possible interpretations usingstatic_cast followed byconst_cast

-- end example ]