From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28967 invoked by alias); 23 Nov 2004 16:09:49 -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 28347 invoked from network); 23 Nov 2004 16:09:20 -0000 Received: from unknown (HELO rproxy.gmail.com) (64.233.170.207) by sourceware.org with SMTP; 23 Nov 2004 16:09:20 -0000 Received: by rproxy.gmail.com with SMTP id j1so558278rnf for ; Tue, 23 Nov 2004 08:09:16 -0800 (PST) Received: by 10.38.77.37 with SMTP id z37mr186248rna; Tue, 23 Nov 2004 08:09:16 -0800 (PST) Received: by 10.38.171.67 with HTTP; Tue, 23 Nov 2004 08:09:16 -0800 (PST) Message-ID: <84fc9c00041123080913f2151d@mail.gmail.com> Date: Tue, 23 Nov 2004 16:31:00 -0000 From: Richard Guenther Reply-To: Richard Guenther To: Michael Matz Subject: Re: generalized lvalues -- patch outline Cc: Gabriel Dos Reis , Daniel Berlin , Nathan Sidwell , Ziemowit Laski , Steve Naroff , gcc mailing list , Matt Austern , Joe Buck , Andrew Pinski , Mike Stump In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4D2CF60C-3919-11D9-8BD2-000A95BCF344@apple.com> <9CD04F70-3CC6-11D9-B847-000D9330C50E@apple.com> <41A253A2.1050205@codesourcery.com> <24BB97A2-3CD3-11D9-B847-000D9330C50E@apple.com> <41A30346.8050602@codesourcery.com> X-SW-Source: 2004-11/txt/msg00822.txt.bz2 On Tue, 23 Nov 2004 16:57:58 +0100 (CET), Michael Matz wrote: > > > Hi, > > On Tue, 23 Nov 2004, Gabriel Dos Reis wrote: > > > > > Probably, this sort of situations probably happen because some people > > have been encouraged in conceiving programming as an activity of > > throwing random codes to the compiler and see what happens. > > Possible. This is one of the ways to learn programming. And despite what > the language standard says, to my eyes "(T*)p++" looks like a natural way > to write p+=sizeof(T), so I'm somewhat sympathetic to programmers using > this construct. Especially as it would need p = (__typeof__(p))((char *)p + sizeof(T)); If you restrict *(T*)p++ to p of char* or void* type, how many broken packages would be left? I think at least those should be fixed. Richard. > Ciao, > Michael. >