From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9569 invoked by alias); 2 Nov 2003 21:10:17 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 9562 invoked by alias); 2 Nov 2003 21:10:17 -0000 Date: Sun, 02 Nov 2003 21:10:00 -0000 Message-ID: <20031102211017.9561.qmail@sources.redhat.com> From: "jsm at polyomino dot org dot uk" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20031102182114.12877.falk@debian.org> References: <20031102182114.12877.falk@debian.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug c/12877] conditional as lvalue gives wrong warning X-Bugzilla-Reason: CC X-SW-Source: 2003-11/txt/msg00091.txt.bz2 List-Id: PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12877 ------- Additional Comments From jsm at polyomino dot org dot uk 2003-11-02 21:10 ------- Subject: Re: New: conditional as lvalue gives wrong warning On Sun, 2 Nov 2003, falk at debian dot org wrote: > But it's a conditional, not a cast, and I think this extension isn't > deprecated. The cast is implicit; the semantics of conditional expressions mean that the chars are converted to a common type of int before the conditional expression is applied to them. Essentially, the extension in question wasn't properly thought out for anything other than the case of a common type that is unaffected by the integer promotions. The problem is arguably that we don't get a hard error here. A similar case where instead of a straight assignment the conditional expression was being used as an output for an asm was rejected (PR 11564); the types there were different but the problem applies just as much where they are the same but get promoted. This extension only isn't deprecated *yet* so that the deprecations (and any associated problems) could be dealt with one at a time. PR 11427 has a specific suggestion that it be deprecated and no objections thereto. I'm inclined on that basis to go ahead with deprecating conditional expressions as lvalues in C for 3.4, and then follow with compound expressions, also for 3.4.