From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7743 invoked by alias); 23 Oct 2002 04:36:02 -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 7710 invoked by uid 71); 23 Oct 2002 04:36:01 -0000 Resent-Date: 23 Oct 2002 04:36:01 -0000 Resent-Message-ID: <20021023043601.7707.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 6006 invoked by uid 61); 23 Oct 2002 04:29:40 -0000 Message-Id: <20021023042940.6005.qmail@sources.redhat.com> Date: Tue, 22 Oct 2002 21:36: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++/8316: Confusing diagnostic for code that misuses conversion operators X-SW-Source: 2002-10/txt/msg00861.txt.bz2 List-Id: >Number: 8316 >Category: c++ >Synopsis: Confusing diagnostic for code that misuses conversion operators >Confidential: no >Severity: serious >Priority: medium >Responsible: unassigned >State: open >Class: sw-bug >Submitter-Id: net >Arrival-Date: Tue Oct 22 21:36:00 PDT 2002 >Closed-Date: >Last-Modified: >Originator: austern@apple.com >Release: 3.1, 3.2, pre-3.3 TOT >Organization: >Environment: Linux >Description: Consider the following code fragment: struct X { char &operator[](char i); operator char *(); operator const char *() const; }; void f(X &x) { x[0] += 1; } Obviously this is bad practice, since x[0] should be interpreted too ways. The compiler ought to tell the programmer that he/she is doing something wrong. The compiler does do that. However, the diagnostic is so confusing that a user who would make this mistake is unlikely to be able to figure out what the compiler is saying. With 3.1 and 3.2, the output is: bash-2.05$ /usr/local/gcc-3.1/bin/g++ -c foo.cc foo.cc: In function `void f(X&)': foo.cc:11: choosing `char& X::operator[](char)' over `operator[]' foo.cc:11: because worst conversion for the former is better than worst conversion for the latter foo.cc:11: choosing `char& X::operator[](char)' over `operator[]' foo.cc:11: because worst conversion for the former is better than worst conversion for the latter Note that (1) the warning is repeated; and (2) it doesn't get to the heart of the matter and tell the user that it's a bad idea to provide both operator* and operator[]. A user is unlikely to be able to understand the problem from reading this message. With 3.3 the behavior is exactly the same, except that 'warning' is replaced by 'error'. This is not an improvement. >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: