From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6579 invoked by alias); 19 Nov 2004 21:50:13 -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 6561 invoked from network); 19 Nov 2004 21:50:05 -0000 Received: from unknown (HELO Cantor.suse.de) (195.135.220.2) by sourceware.org with SMTP; 19 Nov 2004 21:50:05 -0000 Received: from hermes.suse.de (hermes-ext.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id CE33D1136B19; Fri, 19 Nov 2004 22:50:04 +0100 (CET) Date: Fri, 19 Nov 2004 22:24:00 -0000 From: Michael Matz To: Matt Austern Cc: Mike Stump , Joe Buck , Andrew Pinski , gcc mailing list Subject: Re: generalized lvalues In-Reply-To: <98C86CD4-39E2-11D9-B2D5-000A95BCF344@apple.com> Message-ID: 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 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004-11/txt/msg00700.txt.bz2 Hi, On Thu, 18 Nov 2004, Matt Austern wrote: > But I'll give two examples (details changed partly to protect the guilty and > partly because I'm doing this by memory): > (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. Ciao, Michael.