From owner-svn-src-all@freebsd.org Sun May 22 07:58:02 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4907BB44045; Sun, 22 May 2016 07:58:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BEAFF13D3; Sun, 22 May 2016 07:58:01 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u4M7vuON011666 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 22 May 2016 10:57:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u4M7vuON011666 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u4M7vsOI011665; Sun, 22 May 2016 10:57:54 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 22 May 2016 10:57:54 +0300 From: Konstantin Belousov To: Chris Torek Cc: Bruce Evans , Conrad Meyer , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r300332 - in head/sys: amd64/amd64 i386/i386 Message-ID: <20160522075754.GH89104@kib.kiev.ua> References: <20160522101943.U1190@besplex.bde.org> <201605220129.u4M1Topw010808@elf.torek.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201605220129.u4M1Topw010808@elf.torek.net> User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2016 07:58:02 -0000 On Sat, May 21, 2016 at 06:29:50PM -0700, Chris Torek wrote: > On the other hand, since most C compilers don't bother to trap > signed integer overflow, but some can, signed integers may behave > just as badly. :-) > > Overall I personally find the rules simpler for unsigned integers > (occasionally surprising, but predictable and provable behavior in > the mod-2^k ring) than for signed integers (occasionally > surprising, possible trap on overflow, possible nonsense on > overflow, unpredictable and hence unprovable in general). > > The ANSI C folks in 1989 made a mess with the "value preserving" > rules where unsigned integers become signed integers if the > widened type is capable of representing all the values of the > narrower type, but become wider unsigned integers if the widened > type is not capable of representing all these values. The biggest mess in ANSI C is that STD left signed arithmetic undefined on overflow for 2-complement machines. It might be too bold, but IMO significant number, if not all, programmers have a model of signed integer operations on the typical modern real-machine (x86 or riscs) where signed op is done by bit-preserving convertion to unsigned and then doing unsigned op. It is quite possible that standard authors did not even considered that a practically useful compiler could do this differently. The hole was used by one of the compilers to get ever important additional .5% in an artifical benchmarks. Unfortunately gcc went the same route, adopting both undef behaviour claim and colored error messages. We use -fwrapv for kernel.