From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4472 invoked by alias); 23 Nov 2004 21:45:44 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 4429 invoked from network); 23 Nov 2004 21:45:36 -0000 Received: from unknown (HELO mail.codesourcery.com) (65.74.133.9) by sourceware.org with SMTP; 23 Nov 2004 21:45:36 -0000 Received: (qmail 21939 invoked from network); 23 Nov 2004 21:45:36 -0000 Received: from localhost (HELO digraph.polyomino.org.uk) (joseph@127.0.0.1) by mail.codesourcery.com with DES-CBC3-SHA encrypted SMTP; 23 Nov 2004 21:45:36 -0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.42) id 1CWiTe-0005Cg-3F; Tue, 23 Nov 2004 21:45:34 +0000 Date: Tue, 23 Nov 2004 22:09:00 -0000 From: "Joseph S. Myers" X-X-Sender: jsm28@digraph.polyomino.org.uk To: Ziemowit Laski cc: gcc mailing list Subject: Re: generalized lvalues -- patch outline In-Reply-To: Message-ID: References: <4D2CF60C-3919-11D9-8BD2-000A95BCF344@apple.com> <20041117212847.A26376@synopsys.com> <6F5FC748-7BBD-44B9-8DDC-246949F16102@apple.com> <20041118102741.A8347@synopsys.com> <77E8D36A-C0C2-4B03-964C-BEE0FE7BBBC3@apple.com> <98C86CD4-39E2-11D9-B2D5-000A95BCF344@apple.com> <20041119170011.A30410@synopsys.com> <9E6AD708-3A93-11D9-9070-000D9330C50E@apple.com> <20041119174042.A1311@synopsys.com> <90DC5074-3A96-11D9-9070-000D9330C50E@apple.com> <9CD04F70-3CC6-11D9-B847-000D9330C50E@apple.com> <41A253A2.1050205@codesourcery.com> <24BB97A2-3CD3-11D9-B847-000D9330C50E@apple.com> <41A30346.8050602@codesourcery.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004-11/txt/msg00849.txt.bz2 On Tue, 23 Nov 2004, Ziemowit Laski wrote: > Under the conditions specified above, > > (foo)bar > > could be rewritten to > > *((foo *)&bar) You seem to be implying that the address of a cast could be taken. This was not part of the old GNU extension. You are also implying that if "foo" and "typeof(bar)" are not types which may alias, then there is runtime undefined behavior by strict-aliasing rules. I don't think this is what you intend. > > Do you have an analysis of interaction with existing features? > > I don't, although I'm not sure what would constitute "analysis" in this > context. Write down the textual amendments to C99+TC1+TC2 and C++03 which would introduce your feature. Examine *every* reference to "lvalue" in either of those standards and explain how your changes interact with that reference. That's a *minimum* of analysis that would be needed for this. > Are you asking, "how are programmers likely to misconstrue what this extension > does"? I think most programmers out there would probably be surprised that > this is an extension at all, since most would expect something like > > (foo)bar = value; > > to simply "work" :-); so probably the biggest pitfall would be that, even with > the extension enabled, programmers will still get non-lvalue errors sometimes > and then wonder why. People don't need to have read the standards to be aware that casts aren't lvalues; for example, having read K&R would suffice. I don't think we should accept random junk just because someone who hasn't familiarised themselves with the language might throw it at the compiler: we should inform them of the problem with their code and thereby help them to learn the languages better. The use in glibc's RPC headers was not using any actual part of the semantics of lvalue casts; it was accidental and e.g. Sun's RPC headers achieved the proper specification without needing any lvalue casts or similar junk. I must suspect many other uses are similar. People expect new major versions to break things. 4.0 is an excellent opportunity to deprecate or remove unwise features, of which lvalue casts were one. > Yes, they are all applicable, although any one of them taken separately is > sufficient justification, IMO. MS cnd CW compatibility is important because The removal of crufty code, improving the maintainability of the compiler, is sufficient justification for the removal of a dubious extension which does not add expressive power to the language. -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ jsm@polyomino.org.uk (personal mail) joseph@codesourcery.com (CodeSourcery mail) jsm28@gcc.gnu.org (Bugzilla assignments and CCs)