From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29237 invoked by alias); 23 Nov 2004 22:14:34 -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 29161 invoked from network); 23 Nov 2004 22:14:25 -0000 Received: from unknown (HELO mail.codesourcery.com) (65.74.133.9) by sourceware.org with SMTP; 23 Nov 2004 22:14:25 -0000 Received: (qmail 25375 invoked from network); 23 Nov 2004 22:14:24 -0000 Received: from localhost (HELO ?192.168.189.167?) (nathan@127.0.0.1) by mail.codesourcery.com with SMTP; 23 Nov 2004 22:14:24 -0000 Message-ID: <41A3B637.9030706@codesourcery.com> Date: Tue, 23 Nov 2004 22:24:00 -0000 From: Nathan Sidwell Organization: Codesourcery LLC User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 MIME-Version: 1.0 To: Ziemowit Laski CC: Steve Naroff , gcc mailing list , Matt Austern , Michael Matz , Joe Buck , Andrew Pinski , Mike Stump Subject: Re: generalized lvalues -- patch outline 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> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-11/txt/msg00852.txt.bz2 Ziemowit Laski wrote: > 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. Ok, so whether this extension is applicable is implementation defined, based on the sizes of the supported data types. C and C++ standards do not currently have such conditionally defined behaviour (although there are moves to define such a term in C++ at least). >>> - 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. This is an implementation assumption. Some machines have different bit representations for char * and int * pointers for instance (do we support them, I don't know). So, this is another implementation restriction. > 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. so (short)longValue should not touch longValue's bits outside of a short? But I thought you were restricting to casts between object pointer types, so why is this relevent? >>> - 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. so '(foo *)ary' is permitted? >> 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? I don't know. you tell me, you're the one specifying this extension > >> 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. do you mean that these examples must be accepted by the extension? AFAICT the first one (int *)(void *)p does not as currently specified, because (void *)p is not an lvalue cast as it's not being assigned to or modified. If these are to be accepted, something is lacking in the specification. >> 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) this rewriting rule falls foul of the type based aliasing rules. >> 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. Well, consider all the existing language features and show how they are either unaffected, or the changes are not detrimental. > 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. I showed your rewriting rules break existing optimizations (or other ways around, existing optimizations will cause your rewriting rule to generate code that does not do what your extension claims to do). I find 'off the top of my head' to be an unsatisfactory way of defining language extensions. > 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 am asking what currently rejected programs that *really* are programming errors, would silently be accepted, and then lead to hard to debug problems. > 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. I beg to differ. I have no data on what 'most' C programmers think about bits of code that are not specified in the C standard, or any book that teaches standard C or in the gcc documentation. How have you determined what 'most' programmers think about this? >> 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). What code is being brought over? If compatibility is important, what are the specifications of MS's and CW's extensions. It appears this information is being gathered. It would be useless to implement a partial extension, if the main use in the ported code was a different bit of the extension. > 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. From this I understand that the use in Apple's code is accidental, as you've not shown the coding guidelines. You've not followed up on the ObjC rationale. Is that an issue or not? nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery LLC nathan@codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk