This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
c++/8041: Array to pointer conversion in cast expression
- From: austern at apple dot com
- To: gcc-gnats at gcc dot gnu dot org
- Date: 25 Sep 2002 18:24:50 -0000
- Subject: c++/8041: Array to pointer conversion in cast expression
- Reply-to: austern at apple dot com
>Number: 8041
>Category: c++
>Synopsis: Array to pointer conversion in cast expression
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: rejects-legal
>Submitter-Id: net
>Arrival-Date: Wed Sep 25 11:26:02 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator: austern@apple.com
>Release: 2.96 (Redhat), 3.1, 3.2, 3.3 TOT
>Organization:
>Environment:
Linux
>Description:
Consider the following file:
void foo() {
typedef int (&AP)[2][2];
int a[2][2];
#ifdef NEW_STYLE_CAST
AP ap = static_cast<AP>(a);
#else
AP ap = (AP) a;
#endif
}
With all of the versions I listed above: this code compiles without error if -DNEW_STYLE_CAST is on the command line, but omitting it yields this error message:
ap.cc:8: cannot convert `int (*)[2]' to `int[2][2]' in converting
The reason for the error message is that the compiler is applying the array-to-pointer standard conversion, so the argument to the cast expression is of type int (*)[2], which can't be cast to type AP.
I believe the compiler is incorrect in applying that standard conversion for the old-style cast, and that the static_cast behavior is right. (Obviously one of the two must be wrong.)
Here's an analysis from William Miller, posted on the committee reflector:
5.2.9p2 says that "static_cast<T>(e)" is well-formed if the
declaration "T t(e);" is, and the effect is the same as using
"t". In this case, if "int (&t)[2](a)" is well-formed, the
static_cast is as well. In other words, it depends on how
"a" is declared, but it's not automatically an error.
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted: