From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14547 invoked by alias); 23 Nov 2004 21:10:23 -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 14528 invoked from network); 23 Nov 2004 21:10:18 -0000 Received: from unknown (HELO mail-out3.apple.com) (17.254.13.22) by sourceware.org with SMTP; 23 Nov 2004 21:10:18 -0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id iANLGaMF009001 for ; Tue, 23 Nov 2004 13:16:36 -0800 (PST) Received: from relay1.apple.com (relay1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.14) with ESMTP id for ; Tue, 23 Nov 2004 13:11:03 -0800 Received: from [17.201.24.57] (polskifiat.apple.com [17.201.24.57]) by relay1.apple.com (8.12.11/8.12.11) with ESMTP id iANLAECN019628; Tue, 23 Nov 2004 13:10:14 -0800 (PST) In-Reply-To: <41A30346.8050602@codesourcery.com> 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 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Steve Naroff , gcc mailing list , Matt Austern , Michael Matz , Joe Buck , Andrew Pinski , Mike Stump From: Ziemowit Laski Subject: Re: generalized lvalues -- patch outline Date: Tue, 23 Nov 2004 21:34:00 -0000 To: Nathan Sidwell X-SW-Source: 2004-11/txt/msg00846.txt.bz2 On 23 Nov 2004, at 1.30, Nathan Sidwell wrote: > Ziemowit Laski wrote: > >> The semantics are that a C-style cast of an lvalue will itself be >> treated as an lvalue under the following circumstances: > > Thanks for your description, but I find it incomplete. > >> - The lvalue cast does not induce a type conversion (if it does, >> then we use the type conversion instead); > > You can't possibly mean this. If the cast does not change the type, > then > there's no reason to have it there. Clearly some type conversions are > permitted and some not -- please be specific about which. May be > you meant integral conversion, maybe you meant integral-pointer > conversions > maybe you meant integral promotion ... By "inducing a type conversion", I meant generating code to make the conversion happen, as in '(float)intValue'. Perhaps I should have said 'non-trivial type conversion' or some such. In C, conversions among pointer types should always be trivial, but in C++, conversion operators could kick in. In those non-trivial cases, we would disallow the lvalue cast. > >> - The lvalue cast is being assigned to, incremented or decremented; > ... or modified. What is the bitrepresentation of the lvalue? Is it > that of the newly specified type, or is the static type of the > location? Since we're talking about pointers, the bit representation does not change. Microsoft also allows lvalue casts so long as the type being cast to is not larger than the original type (e.g., '(short)longValue' is OK whereas '(long)shortValue' is not); in those cases, I'm fairly certain we want the bit layout of the newly specified type. >> - The lvalue is of a pointer type, and is being cast to a pointer >> type. > ok, so this answers my questions about point 1. Any pointer type? Like > the disallowed func->object conversion in C++? What about references > and/or references to pointer types? Does array/function->pointer > decay occur? It might make sense to restrict the original lvalue > type to 'void *'. Just plain C pointers ('foo *', 'bar *'); no references and no pointers-to-members, although I see no reason why we should disallow arrays and function pointers. > > Are there any restrictions on the original lvalue that is being cast? I don't understand this question -- what kind of restrictions could/should there be? > Is this extension composable? For instance what about the following, > #define MAGIC_REGISTER ((void *)p) > (int *)MAGIC_REGISTER += 2 > > What about > (expr, (int *)p) = something > in C++? In C++ operator, is an lvalue if its second operand is an > lvalue. Similarly for ?: I think the examples you give here should all work. > > Have you thought about specifying this in terms of a rewriting rule? Under the conditions specified above, (foo)bar could be rewritten to *((foo *)&bar) > 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. I suppose you can take the rewrite rule above and then try to see if the rewritten expression would play nicely as an rvalue in other contexts; off the top of my head, I can't think of situations where it would not, though I welcome others to poke holes in this theory. One important thing to note is that the extension I'm proposing does not change existing, valid behavior; it only affects cases that currently (with TOT gcc 4.0) produce hard errors. > What > programming errors would fall into 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. > Why do you want this extension? > I see 6 different possible rationales. Are they all applicable? Yes, they are all applicable, although any one of them taken separately is sufficient justification, IMO. MS cnd CW compatibility is important because of code that is being brought over, but I don't think we necessarily have to implement each corner case of this extension as supported by these (and other) compilers (we could, but that would go way beyond what we are proposing here). Rather, what we are concerned with is how the extensions tend to be used in real code. And most existing usage, both in Apple's case and in examples cited by Michael Matz, has to do with pointer type manipulation. So, even while I'm advocating this feature, I do not wish to bloat it unnecessarily. --Zem