From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3686 invoked by alias); 28 Jun 2005 17:10:29 -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 3678 invoked by uid 22791); 28 Jun 2005 17:10:26 -0000 Received: from host217-40-213-68.in-addr.btopenworld.com (HELO SERRANO.CAM.ARTIMI.COM) (217.40.213.68) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 28 Jun 2005 17:10:26 +0000 Received: from mace ([192.168.1.25]) by SERRANO.CAM.ARTIMI.COM with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Jun 2005 18:10:24 +0100 From: "Dave Korn" To: "'Joe Buck'" Cc: "'Olivier Galibert'" , "'Robert Dewar'" , "'Gabriel Dos Reis'" , "'Andrew Pinski'" , "'gcc mailing list'" Subject: RE: signed is undefined and has been since 1992 (in GCC) Date: Tue, 28 Jun 2005 17:10:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In-Reply-To: <20050628164136.GD9524@synopsys.com> Message-ID: X-SW-Source: 2005-06/txt/msg01150.txt.bz2 ----Original Message---- >From: Joe Buck >Sent: 28 June 2005 17:42 > On Tue, Jun 28, 2005 at 03:39:38PM +0100, Dave Korn wrote: >> ----Original Message---- >>> From: Olivier Galibert >>> Sent: 28 June 2005 15:25 >> >>> In particular, a very large number of C and C++ programs are written >>> with the assumptions: >> >> This is a bad line of reasoning in general. There is a vast amount of >> bad software in the world, some blatantly buggy, some subtly-incorrect. >> To attempt to fix it all in the compiler rather than the source seems a >> bit bass-ackwards to me! >> >>> - sizeof(int) == 4, sizeof(long long) == 8 >>> >>> - sizeof(long) == sizeof(void *) == sizeof(void (*)()) >>> >>> Break them and see your compiler rejected by pretty much everybody. >> >> And what about 64 bit architectures? Your assumptions are already >> widely invalid and only going to get more so. > > No, all of Olivier's assumptions are valid on LP64 as well as ILP32 > architectures. Well, they're invalid on ILP64, but I guess Cray and Alpha T3E aren't very widespread platforms. But we can expect that ILP64 will become more widely used in the future, when the migration from 32-bit platforms starts to become nothing more than a distant memory, can't we? > They are invalid on most DSP architectures, as well as > on 16-bit embedded architectures, which I suppose you could call "widely > invalid" if you count # of shipping parts. I'm sure I remember a post from one of the interminably long threads of the past few weeks that quoted examples of non-standard sizes in some 64-bit arch(es), but I haven't been able to dig it up. > But they are a reasonable > engineering tradeoff in many cases (it's a waste of time in most cases > for a program that does a lot of bit manipulation to consider the case > of 37 bit one's complement architectures with an 11 bit byte). A waste of time in user apps, yes, but not an assumption that we necessarily want to embed in the compiler (and bear in mind I'm not talking about really bizarre stuff with 37 bits or 1's-C or non-8-bit-bytes; I'm talking only about nice power-of-2 sizes and other sane choices here.) cheers, DaveK -- Can't think of a witty .sigline today....