From owner-freebsd-current@FreeBSD.ORG Thu Feb 27 17:04:33 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CA1088EF for ; Thu, 27 Feb 2014 17:04:33 +0000 (UTC) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6AAB21C6E for ; Thu, 27 Feb 2014 17:04:33 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.7/8.14.7) with ESMTP id s1RH4VaG049340; Thu, 27 Feb 2014 12:04:31 -0500 (EST) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.7/8.14.4/Submit) id s1RH4UaU049339; Thu, 27 Feb 2014 12:04:30 -0500 (EST) (envelope-from wollman) Date: Thu, 27 Feb 2014 12:04:30 -0500 (EST) From: Garrett Wollman Message-Id: <201402271704.s1RH4UaU049339@hergotha.csail.mit.edu> To: imb@protected-networks.net Subject: Re: firebox build fails post clang-3.4 merge X-Newsgroups: mit.lcs.mail.freebsd-current In-Reply-To: <530EA5CD.2070508@protected-networks.net> References: <201402270057.s1R0vkjH084327@gw.catspoiler.org> Organization: none X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hergotha.csail.mit.edu [127.0.0.1]); Thu, 27 Feb 2014 12:04:31 -0500 (EST) X-Spam-Status: No, score=-0.4 required=5.0 tests=ALL_TRUSTED,URIBL_SBL autolearn=disabled version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hergotha.csail.mit.edu X-Mailman-Approved-At: Thu, 27 Feb 2014 17:07:41 +0000 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 17:04:33 -0000 In article <530EA5CD.2070508@protected-networks.net>, imb@protected-networks.net writes: > .. way back in the late 70's or maybe early 80's when I was >actually doing some work on compilers, we had a saying: "produce correct >code even if it's not optimal or exit and tell the user why". > >Producing non-working code for no apparent reason and without warning is >counter-productive. It wastes everyone's time :-( When the specification of "correct" says that anything can happen, including but not limited to the program crashing at runtime, there's no limit on what the compiler may emit. (On the other hand, I agree that if the compiler emits a "crashme" instruction, it really ought to generate a diagnostic as well, even if it can't explain why.) Originially this "escape hatch" was intended to apply to conditions that the compiler could not detect (or at least, the historical PCC could not detect), but nowadays the compiler writers take it upon themselves to deliberately break programs that involve undefined behavior, even when there is an entirely sensible way to define the behavior which is consonant with the way the machine architecture works and how historical compilers have implemented the same construct. For example, the following program: #include extern long l; int main(void) { l = LONG_MAX; l++; return l > 0; } ..is permitted to crash, but it's also permitted to do nothing, and it's permitted to set l to LONG_MIN (following the normal two's-complement arithmetic on signed values). The compilers I checked actually did the obvious thing, but they are older versions. -GAWollman