From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14914 invoked by alias); 25 Sep 2002 18:26:05 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 14879 invoked by uid 71); 25 Sep 2002 18:26:05 -0000 Resent-Date: 25 Sep 2002 18:26:05 -0000 Resent-Message-ID: <20020925182605.14878.qmail@sources.redhat.com> Resent-From: gcc-gnats@gcc.gnu.org (GNATS Filer) Resent-Cc: gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org Resent-Reply-To: gcc-gnats@gcc.gnu.org, austern@apple.com Received: (qmail 14000 invoked by uid 61); 25 Sep 2002 18:24:50 -0000 Message-Id: <20020925182450.13999.qmail@sources.redhat.com> Date: Wed, 25 Sep 2002 11:26:00 -0000 From: austern@apple.com Reply-To: austern@apple.com To: gcc-gnats@gcc.gnu.org X-Send-Pr-Version: gnatsweb-2.9.3 (1.1.1.1.2.31) Subject: c++/8041: Array to pointer conversion in cast expression X-SW-Source: 2002-09/txt/msg00672.txt.bz2 List-Id: >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(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(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: