From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27093 invoked by alias); 19 Jun 2005 10:18:35 -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 27080 invoked by uid 22791); 19 Jun 2005 10:18:31 -0000 Received: from colo.khms.westfalen.de (HELO colo.khms.westfalen.de) (213.239.196.208) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sun, 19 Jun 2005 10:18:31 +0000 Received: from khms.vpn ([10.172.192.2]:40278 helo=khms.westfalen.de) by colo.khms.westfalen.de with esmtpsa (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1Djwsm-0007AY-VN for gcc@gcc.gnu.org; Sun, 19 Jun 2005 12:18:29 +0200 Received: from root (helo=khms.westfalen.de) by khms.westfalen.de with local-bsmtp (Exim 4.50) id 1Djwsj-0006fg-SO for gcc@gcc.gnu.org; Sun, 19 Jun 2005 12:18:25 +0200 Received: by khms.westfalen.de (CrossPoint v3.12d.kh15 R/C435); 19 Jun 2005 12:10:42 +0200 Date: Sun, 19 Jun 2005 10:18:00 -0000 From: kaih@khms.westfalen.de (Kai Henningsen) To: gcc@gcc.gnu.org Message-ID: <9Z96F2j1w-B@khms.westfalen.de> In-Reply-To: <87oea3gz29.fsf@deneb.enyo.de> Subject: Re: basic VRP min/max range overflow question MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii References: <87oea3gz29.fsf@deneb.enyo.de> X-No-Junk-Mail: I do not want to get *any* junk mail. X-Fix-Your-Modem: +++ATS2=255&WO1 X-SW-Source: 2005-06/txt/msg00805.txt.bz2 fw@deneb.enyo.de (Florian Weimer) wrote on 18.06.05 in <87oea3gz29.fsf@deneb.enyo.de>: > * Paul Schlie: > > > So in effect the standard committee have chosen to allow any program which > > invokes any undefined behavior to behave arbitrarily without diagnosis? > > > > This is a good thing? > > It's the way things are. There isn't a real market for > bounds-checking C compilers, for example, which offer well-defined > semantics even for completely botched pointer arithmetic and pointer > dereference. > > C isn't a programming language which protects its own abstractions > (unlike Java, or certain Ada or Common Lisp subsets), and C never was > intended to work this way. Consequently, the committee was right to > deal with undefined behavior in the way it did. Otherwise, the > industry would have adopted C as we know it, and the ISO C standard > would have had the same relevance as, say, the ISO Pascal on the > evolution of Pascal. And yet, languages like ISO Pascal *still* define undefined behaviour pretty much the same way C does. They just choose a different set of situations (well, there *is* overlap) to apply it to. Pretty much all languages which allow access to "the bare metal" need this escape clause, because making a program safe in that context pretty much requires the compiler to solve the halting problem or equivalent - and we can't do that. The alternative is putting enough padding between the program and the metal to enable the compiler and runtime system significantly more control - and, of course, giving the programmer significantly *less* control. For example, there won't be any type-punning in such a language. It's a very different trade-off. MfG Kai