From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6082 invoked by alias); 28 Jun 2005 20:37:36 -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 6069 invoked by uid 22791); 28 Jun 2005 20:37:32 -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 20:37:32 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id 30FC89639; Tue, 28 Jun 2005 16:37:31 -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 02670-01-7; Tue, 28 Jun 2005 16:37:31 -0400 (EDT) Received: from [127.0.0.1] (taconic.gnat.com [205.232.38.103]) by nile.gnat.com (Postfix) with ESMTP id F17F3960F; Tue, 28 Jun 2005 16:37:30 -0400 (EDT) Message-ID: <42C1B509.7050605@adacore.com> Date: Tue, 28 Jun 2005 20:37:00 -0000 From: Robert Dewar User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) MIME-Version: 1.0 To: Gabriel Dos Reis CC: Andrew Pinski , Olivier Galibert , 'gcc mailing list' , 'Andrew Haley' , Dave Korn Subject: Re: signed is undefined and has been since 1992 (in GCC) References: <20050628180203.GG52889@dspnet.fr.eu.org> <20050628191006.GI52889@dspnet.fr.eu.org> <882882640c20778910272cdd8e19eff4@physics.uc.edu> <42C1A5AF.3090905@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/msg01196.txt.bz2 Gabriel Dos Reis wrote: > Robert Dewar writes: > > | Gabriel Dos Reis wrote: > | > | > The strict aliasing rule by itself does not show it is not a high level > | > assembly language. There are chips out there where you cannot access > | > data willy-nilly through random register types. > | > | And there are chips for which signed arithmetic is not wrap around! > > yes, but that is irrelevant, the assumptin was made that > one knows what the chip provides. And if the chip provides two consistent models of arithmetic, you cannot deduce from the standard that one is preferred over the other (e.g. logical vs arithmetic instructions on the IBM mainframe, or trapping vs non-trapping arithmetic on the MIPS). I would actually think that the trapping arithmetic on the MIPS is a much better model of signed int's in C (the language as defined by the standard) [of course, given the claim that so few people know C, and those who do not have expectations, you may well decide to meet those expectations if it is free to do so). A good analogy here is Fortran allocation. Everyone *knows* that Fortran allocates storage statically, and many programs rely on this, but even Fortran-66 went to great pains to NOT say this, and a stack based implementation was entirely conforming. However, as Burroughs found out, a stack based Fortran was not very useable. As I said in an earlier message, the issue here is one of tradeoffs. You always prefer defined behavior to undefined, and if you cannot have defined, the equivalent of Ada bounded error is still a huge improvement over undefined. If there were no tradeoff with efficiency, there is an argument for testing for every undefined situation at run time and raising a signal when it occurs with an appropriate message. THat's of course impractical. Failing that, if there is a sort of expected behavior (e.g. everyone knows function pointers are the same length as int pointers), then it is good to conform to this expectation if it can be done cheaply (are trampolines cheap enough? probably not). In the case of overflow, everyone would agree on avoiding the undefined behavior if it is cheap enough. If it is not cheap enough, then I think most people would accept the undefined status. How can you make an informed decision with no data in a case like this? Answer you can't!