From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27953 invoked by alias); 20 Nov 2004 00:41:51 -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 27889 invoked from network); 20 Nov 2004 00:41:36 -0000 Received: from unknown (HELO mail-out3.apple.com) (17.254.13.22) by sourceware.org with SMTP; 20 Nov 2004 00:41:36 -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 iAK0li4c027859 for ; Fri, 19 Nov 2004 16:47:44 -0800 (PST) Received: from relay3.apple.com (relay3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.14) with ESMTP id ; Fri, 19 Nov 2004 16:42:16 -0800 Received: from [17.201.24.57] (polskifiat.apple.com [17.201.24.57]) by relay3.apple.com (8.12.11/8.12.11) with ESMTP id iAK0fXRi029646; Fri, 19 Nov 2004 16:41:33 -0800 (PST) In-Reply-To: References: <8AD5AEEF-3914-11D9-8BD2-000A95BCF344@apple.com> <78169FF3-3916-11D9-AEB4-000A95D692F4@physics.uc.edu> <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> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Matt Austern , Mike Stump , Joe Buck , Andrew Pinski From: Ziemowit Laski Subject: Re: generalized lvalues Date: Sat, 20 Nov 2004 01:00:00 -0000 To: Michael Matz , gcc mailing list X-SW-Source: 2004-11/txt/msg00707.txt.bz2 On 19 Nov 2004, at 13.50, Michael Matz wrote: >> (1) #define foo(x) *(a, b, x) >> (2) ((long*) p)++ > > Actually, from my experience looking at assorted packages which are > tried > to be build with 4.0, the latter use is most common. I.e. casting a > pointer to some type to implicitely specify how much it is incremented. > Some software is very much known for using such constructs (wine, rpm, > elfutils, dietlibs, many others) . I even tend to say, that such > usage is > well defined (within certain limits), although I admit that it's not > ISO > C99. > > > All the whining about how unspecified this is, and how the writer of > the > code deserve to be bitten, is just language lawyer masturbation (which > I > also very much enjoy when closing bugreports about this or that > compiler > bug with INVALID), but it doesn't change the fact, that there are quite > some packages out there actually using such extensions. This > cast-as-lvalue extension removal is one of the bigger items which > result > in much work for package maintainers (not so much for C++, as there > anyway > this extension wasn't used much). > > > So, if anyone wants to bring it back, with defined semantics of course > (like for instance memory accessed through a casted pointer is well > defined (not outside the memory for the object accessed), and only for > C) > I'm all ears. As I've alluded to in an earlier e-mail, bringing back the entire cast-as-lvalue functionality is probably not necessary (and yes, it can interact rather badly with C and C++, as I have finally been convinced). However, I did make a suggestion that we could create a special flag (e.g., '-fassign-to-cast' or some such) that would allow an assignment (including ++ and --) to a cast. Would such an approach be acceptable? Thanks, --Zem