From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28512 invoked by alias); 23 Nov 2004 09:31:17 -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 28325 invoked from network); 23 Nov 2004 09:30:55 -0000 Received: from unknown (HELO mail.codesourcery.com) (65.74.133.9) by sourceware.org with SMTP; 23 Nov 2004 09:30:55 -0000 Received: (qmail 16733 invoked from network); 23 Nov 2004 09:30:54 -0000 Received: from localhost (HELO ?192.168.189.167?) (nathan@127.0.0.1) by mail.codesourcery.com with SMTP; 23 Nov 2004 09:30:54 -0000 Message-ID: <41A30346.8050602@codesourcery.com> Date: Tue, 23 Nov 2004 09:54: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> In-Reply-To: <24BB97A2-3CD3-11D9-B847-000D9330C50E@apple.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-11/txt/msg00799.txt.bz2 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 ... > - 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? (I.e. what would a C interpreter that tracks dynamic type say about that lvalue's 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 *'. Are there any restrictions on the original lvalue that is being cast? 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 ?: Have you thought about specifying this in terms of a rewriting rule? Do you have an analysis of interaction with existing features? What programming errors would fall into this? > (This will need to be relaxed somewhat should people desire > Microsoft compatibility, at least for C.) ahh, this leads me on to a rationale. Why do you want this extension? I see 6 different possible rationales. Are they all applicable? 1) Microsoft VC++ compatibility. What are the specifications of this extension? (I see Matt is trying to find out.) If this is the reason, the whole of that extension should be implemented, and it should be enabled on the existing -fms-extensions flag. 2) CodeWarrior compatibility. Same questions. Is the CW extension exactly the same as the VC++ extension? There should be a -fcw-extensions flag if we want to go down that route. 3) It is used in Apple's code base. Mike Stump posted some numbers. Can you provide Apple's coding guidelines that document where this extension can be used, and what the semantics are presumed to be? I understand the Linux kernel had some uses, but they have all been removed in the 2.6 series, because of their removal from gcc. I have no idea on the relative task sizes of removing it from Linux's and Apple's code base. 4) It is in use in other code that is 'out there'. What code? Give examples. Given that one of the biggest bits (Linux kernel) has been cleaned, this other code needs to be widely used and difficult to clean. Andrew, what fraction of 3.4 bug reports concern this feature? (Does the C FE give a deprecated warning, or are C users in the dark?) 5) Some ObjC/ObjC++ garbage collection proposal. Other syntaxes have been proposed. I've not seen a detailed description of this proposal. 6) It leads to clearer, more understandable code. It seems to me the only thing that would be clearer is void *p = something; (int *)p += offset; ... maybe. I do not find this compelling. This code is what one finds in memory allocators, and their implementation is few and far between. In an allocator one would either make P a 'char *' or provide an inline function/macro to do the adjustment. I do not like the idea of special flags per extension. That way lies N^2 different 'interesting' failure modes. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery LLC nathan@codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk