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. _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"