From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1097 invoked by alias); 28 Jun 2005 19:43:40 -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 1013 invoked by uid 22791); 28 Jun 2005 19:43:29 -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 19:43:29 +0000 Received: from uniton.integrable-solutions.net (gdr.net1.nerim.net [62.212.99.186]) by kraid.nerim.net (Postfix) with ESMTP id 05EB240F53; Tue, 28 Jun 2005 21:43:25 +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 j5SJgmKY005286; Tue, 28 Jun 2005 21:42:48 +0200 Received: (from gdr@localhost) by uniton.integrable-solutions.net (8.12.10/8.12.10/Submit) id j5SJgmEX005285; Tue, 28 Jun 2005 21:42:48 +0200 To: Robert Dewar Cc: Olivier Galibert , Andrew Haley , Dave Korn , "'Andrew Pinski'" , "'gcc mailing list'" Subject: Re: signed is undefined and has been since 1992 (in GCC) References: <20050628142441.GA52889@dspnet.fr.eu.org> <20050628145148.GD52889@dspnet.fr.eu.org> <17089.26325.169281.749633@zapata.pink> <20050628171752.GE52889@dspnet.fr.eu.org> <42C19BE8.9050107@adacore.com> <42C1A23F.6000806@adacore.com> From: Gabriel Dos Reis In-Reply-To: <42C1A23F.6000806@adacore.com> Date: Tue, 28 Jun 2005 19:43:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2005-06/txt/msg01189.txt.bz2 Robert Dewar writes: | Gabriel Dos Reis wrote: | > Robert Dewar writes: | > | Olivier Galibert wrote: | > | | > Calling a large part of the programs out there, including a non | > | > negligible subpart of what I personally write either "blatantly buggy" | > | > or "subtly-incorrect" is somewhat childish and insulting. | > | | nope, I don't see it that way at all, this is just a statement | > of fact | > | wrt the ISO standard. You may want C or C++ to be different from what | > | it is, but the standard is widely accepted, | > Those standards are widely accepted and so are very facts that they | > do | > have connections with hardware. In fact, the respective committees | > do work seriously on producing TRs for embedded systems and access to | > hardware semantics. | | I think you miss my point completely about hardware semantics. Let me | try, though I am dubious it will be clear. Maybe because it is an already confused statement? | The type int in C is not | a hardware type, it is a type with properties defined by the standard. | There is not necessarily any unique expectation on how this will be | mapped to hardware, or what operations will be mapped. The only | requirement is that the required semantics of int in the standard | are preserved. For instance on the IBM mainframe one might use signed | or unsigned operations to implement int operations. On the original | MIPS one might use trapping or non-trapping arithmetic (either would | be valid). nice exercise in language lawyering but, I think your forgot the qualification in the claim: if the hardware I'm targetting provides the specific semantics I want. Your scenario does not disqualify it. | Yes, sometimes you need access to the hardware and need to control | exactly what is generated, but using int is not a mechanism that | provides any such guarantee. except that those whose produced the document had an intended semantics and the expectations are connected with some reality which you would deny. [#5] An object declared as type signed char occupies the same amount of storage as a ``plain'' char object. A ``plain'' int object has the natural size suggested by the architecture of the execution environment (large enough to contain any value in the range INT_MIN to INT_MAX as defined in the header ). C and C++ are general programming language geared toward system programming. -- Gaby