From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4641 invoked by alias); 28 Jun 2005 18:28:43 -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 4596 invoked by uid 22791); 28 Jun 2005 18:28:34 -0000 Received: from dspnet.fr.eu.org (HELO dspnet.fr.eu.org) (213.186.44.138) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 28 Jun 2005 18:28:34 +0000 Received: by dspnet.fr.eu.org (Postfix, from userid 1007) id 7C17134D22; Tue, 28 Jun 2005 20:28:32 +0200 (CEST) Date: Tue, 28 Jun 2005 18:28:00 -0000 From: Olivier Galibert To: Joe Buck Cc: Andrew Haley , Dave Korn , 'Robert Dewar' , 'Gabriel Dos Reis' , 'Andrew Pinski' , 'gcc mailing list' Subject: Re: signed is undefined and has been since 1992 (in GCC) Message-ID: <20050628182832.GH52889@dspnet.fr.eu.org> 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> <20050628175039.GB9783@synopsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050628175039.GB9783@synopsys.com> User-Agent: Mutt/1.4.2.1i X-SW-Source: 2005-06/txt/msg01167.txt.bz2 On Tue, Jun 28, 2005 at 10:50:39AM -0700, Joe Buck wrote: > On Tue, Jun 28, 2005 at 07:17:52PM +0200, Olivier Galibert wrote: > > On Tue, Jun 28, 2005 at 04:03:49PM +0100, Andrew Haley wrote: > > > This is childish and insulting. > > > > 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. > > I agree, partly, with Olivier. However, let's not insult each other; > we need to recognize that GCC developers have to worry about embedded > systems, where some of the assumptions Olivier makes do not hold. Oh yes. But you have to be careful not to break them for the non-embedded world, and in any case I was only answering to the affirmation that "C the language is disconnected from the hardware". Incidentally, gcc itself makes most of these assumptions in its own code. I kinda doubt you can run it on a dsp or a machine with 16-bits ints. Which is different than generating code for them. > However, I am careful to document them, and disagree with a couple > (particularly assuming things about unaligned access; even when the > architecture permits it, there's a substantial speed penalty). Sure, and I tend to avoid them too, especially since I still run code on sgis and alphas. Still, they're often considered slow but not crashing in lots of programs out there. > Also, some of Olivier's assumptions could lead to less maintainable > code; sloppy typing can hide errors, even for assumptions that are > safe with all ILP32 and LP64 machines with IEEE FP. The pointer/long interchangeability, thankfully, appears less often. I see it raise its ugly head essentially in cases of printing (%p is recent), pointer difference (which fits in a long but not an int), virtual machines where storage is tightly controlled (lisp engines in particular), and more often when you want to pass a value through a library-opaque void * (thread starts, callbacks) but you do not want to have structure lifetime issues. In these cases you know you can pass up to a long unscathed. > It would be best to say that the assumptions are non-portable, too > non-portable to be used in code contributed to GCC. Some are already there and won't go, the most obvious one is that int is more than 16 bits. There are also some: INDEX_EDGE (edge_list, i)->aux = (void *) (size_t) i; which is I guess one of your cases of sloppy typing. I'm sure we can find a number of assumptions you wouldn't like on the boehm collector too, simply because code so close to the memory management needs them badly. OG.