Date: Sun, 22 May 2016 10:57:54 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Chris Torek <torek@torek.net> Cc: Bruce Evans <brde@optusnet.com.au>, Conrad Meyer <cem@freebsd.org>, 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> In-Reply-To: <201605220129.u4M1Topw010808@elf.torek.net> References: <20160522101943.U1190@besplex.bde.org> <201605220129.u4M1Topw010808@elf.torek.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160522075754.GH89104>