From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23465 invoked by alias); 28 Jun 2005 05:13:12 -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 23443 invoked by uid 22791); 28 Jun 2005 05:13:06 -0000 Received: from smtp-102-tuesday.nerim.net (HELO kraid.nerim.net) (62.4.16.102) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 28 Jun 2005 05:13:06 +0000 Received: from uniton.integrable-solutions.net (gdr.net1.nerim.net [62.212.99.186]) by kraid.nerim.net (Postfix) with ESMTP id 949F740E22; Tue, 28 Jun 2005 07:13:02 +0200 (CEST) Received: from uniton.integrable-solutions.net (localhost [127.0.0.1]) by uniton.integrable-solutions.net (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j5S5CRKY001789; Tue, 28 Jun 2005 07:12:29 +0200 Received: (from gdr@localhost) by uniton.integrable-solutions.net (8.12.10/8.12.10/Submit) id j5S5CRPF001788; Tue, 28 Jun 2005 07:12:27 +0200 To: Andrew Pinski Cc: gcc mailing list Subject: Re: signed is undefined and has been since 1992 (in GCC) References: <27fdc0d8dc588cfdb3a14a153c5d037c@physics.uc.edu> <6d9fa260f233e519762c7d11276a35ad@physics.uc.edu> From: Gabriel Dos Reis In-Reply-To: <6d9fa260f233e519762c7d11276a35ad@physics.uc.edu> Date: Tue, 28 Jun 2005 05:13:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2005-06/txt/msg01078.txt.bz2 Andrew Pinski writes: | On Jun 28, 2005, at 12:34 AM, Gabriel Dos Reis wrote: | | > The attitude that "undefined behaviour" should be interpreted | > as "we should not make things more useful when we can" is beyond | > understanding. | | Then C/C++ aliasing rules go out the window really or maybe I | misunderstand | what you are trying to say? yes, you misunderstand what I'm saying. | And what about casting functions to a different function type and | calling | that, we just declared it as calling a trap in the last couple of years. That is a type constraint violation that leads to subtle runtime errors, so we did actually improve things by catching (potential) errors earlier. As a concrete case at point, the C++ committee just decided at the last meeting in Norway to "upgrade" cast between void* and pointer to function types from "undefined behaviour" to "conditionally supported" -- and interestingly it led to vigurous request from library and application programmers that compilers do document what they are doing in that area. GCC had been a lead there. For the concrete case at issue, if the hardware I'm writing the C/C++ programs for consistently displays modulo arithmetics for signed integer type, Andrew can you tell me why GCC should deny me access to that functionally where it actually can? "Denying" here means that it does not give me access to that consistent hardware behaviour. None of the items on the list you gave falls into that category. Please, do remember that "undefined behaviour" is a catch-all basket and two things in that basket are not necessarily "equally evil". So, please, do refrain from reasoning like "since we did X for Y and Y was undefined behaviour, we should do the same for Z." "Undefined behaviour" isn't a 0 or 1 thingy, even though it is about computers. You need to evaluate them on case-by-case basis. -- Gaby