From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29100 invoked by alias); 28 Jun 2005 12:07:04 -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 29074 invoked by uid 22791); 28 Jun 2005 12:06:59 -0000 Received: from nile.gnat.com (HELO nile.gnat.com) (205.232.38.5) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 28 Jun 2005 12:06:59 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id 1FCEA961E; Tue, 28 Jun 2005 08:06:39 -0400 (EDT) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 23669-01-7; Tue, 28 Jun 2005 08:06:38 -0400 (EDT) Received: from [127.0.0.1] (taconic.gnat.com [205.232.38.103]) by nile.gnat.com (Postfix) with ESMTP id E1A20961A; Tue, 28 Jun 2005 08:06:38 -0400 (EDT) Message-ID: <42C13D4D.9040604@adacore.com> Date: Tue, 28 Jun 2005 12:07:00 -0000 From: Robert Dewar User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) MIME-Version: 1.0 To: Gabriel Dos Reis CC: Andrew Pinski , gcc mailing list Subject: Re: signed is undefined and has been since 1992 (in GCC) References: <27fdc0d8dc588cfdb3a14a153c5d037c@physics.uc.edu> <6d9fa260f233e519762c7d11276a35ad@physics.uc.edu> <3dbad9a6bd7eb1aea74ff2245eaa1b99@physics.uc.edu> <42C115D5.8070503@adacore.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-06/txt/msg01095.txt.bz2 Gabriel Dos Reis wrote: > The issue here is whether if the hardware consistently display a > semantics, GCC should not allow access to that consistent semantics > under the name that "the standard says it is undefined behaviour". > Consider the case of converting a void* to a F*, where F is a function > type. Well the "hardware consistently displaying a semantics" is not so cut and dried as you think (consider the loop instruction and other arithmetic on the x86 for instance in the context of generating code for loops). THis is all about trading off undefined behavior (a bad thing) against high performance (a good thing) against encouraging people to write portable code (a good thing) against existing wrong programs working (probably a good thing, though at odds with the portability requirement). C is not a way of writing machine code, it is an abstract language defined by the standard. There can be arguyments for language extension, as you making, but such decisions should be made with proper data about the magnitude of the tradeoffs. > > -- Gaby