From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-57147-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 16275 invoked by alias); 25 Jul 2002 18:40:34 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 16228 invoked from network); 25 Jul 2002 18:40:32 -0000
Received: from unknown (HELO soliton.integrable-solutions.net) (62.212.99.186)
  by sources.redhat.com with SMTP; 25 Jul 2002 18:40:32 -0000
Received: (from gdr@localhost)
	by soliton.integrable-solutions.net (8.11.6/8.11.6/SuSE Linux 0.5) id g6PIcVZ24174;
	Thu, 25 Jul 2002 20:38:31 +0200
To: Matt Austern <austern@apple.com>
Cc: gcc@gcc.gnu.org
Subject: Re: Address of a cast expression in C++
References: <77823DB0-9FFB-11D6-AF26-00039390D9E0@apple.com>
From: Gabriel Dos Reis <gdr@integrable-solutions.net>
In-Reply-To: Matt Austern's message of "Thu, 25 Jul 2002 11:22:24 -0700"
Organization: CodeSourcery, LLC
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
Date: Thu, 25 Jul 2002 14:30:00 -0000
Message-ID: <m3ofcv7ivs.fsf@soliton.integrable-solutions.net>
X-SW-Source: 2002-07/txt/msg01236.txt.bz2

Matt Austern <austern@apple.com> writes:

| With both 3.1 and TOT, the following program is rejected by
| the C front end but accepted by the C++ front end.  g++
| compiles it without error or warning.
|      #include <stdio.h>
| 
|      int main() {
|        int n = 0;
|        char* p = &(char)n;
|       *p = 0x7f;
|        printf("%x\n", n);
|      }
| 
| As I read the C++ Standard, this is incorrect; a diagnostic is
| required.  5.4/1 says that the result of (char)n is an rvalue,
| and 5.3.1/2 says that you can't take the address of an rvalue.
| 
| Question: is this violation of the C++ Standard deliberate,
| or is it a bug?

I would say it is a result of a bug -- I suspect another instance of
code duplication where the problem is fixed in C but not in C++ :-(

Indeed, the C++ front-end's copy (in typeck.c) of the C front-end's
build_unary_op() (in c-typeck.c) doesn't not handle the case you
spotted.  Yet another instance of "code duplication is evil".

| The reason I ask, of course, is that gcc has a generalized
| lvalue extension.  The manual says that even with this
| extension it's illegal to write &(int)f.  Who's wrong: the manual,
| or the compiler?

The compiler is buggy.

-- Gaby