Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: C wish list Date: Sun, 24 Mar 2019 20:21:01 -0700 Organization: None to speak of Lines: 55 Message-ID: References: <18RkE.296542$DH4.255445@fx24.am4> <2J7lE.185089$1p7.119303@fx05.am4> <2PalE.135956$Ef4.37063@fx38.am4> <4BqlE.730757$RBa.544247@fx15.am4> <32AlE.453865$UO4.70438@fx38.iad> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: reader02.eternal-september.org; posting-host="784bbd8fb1c90ff7036d4663e7b2295d"; logging-data="11797"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX184MS5dMwt6s/Qo/T2/3UZK" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:cO6dW+8p2opuPjJu6yddWU3bVNc= sha1:BKW6+IarruLnwOKqGtm2hDwwheY= Xref: csiph.com comp.lang.c:142391 Richard Damon writes: > On 3/24/19 12:41 PM, David Brown wrote: [...] >> The other commonly cited reason for undefined behaviour on overflow, >> that it would vary between machines, is less convincing to me.  If that >> were a major point, I think the standards would say that integer >> overflow gives either an implementation-defined result or raises an >> implementation-defined signal - that would cover pretty much any system. > > My understanding was that the committee didn't use that phrase in the > initial standard, behavior had a fairly simple hierarchy: > > Defined Behavior: the Standard spelled out exact what should happen. > > Implementation Defined Behavior: The Standard provides a (normally) > explicit set of options which the implementation documents which is chosen. > > Unspecified Behavior: The Standard provieds a (normally) explicit set of > options of which the implementation can choose between, but doesn't need > to be consistent about or document. (Like the order the parts of an > expression are evaluated, absent defined sequence points) > > Undefined Behavior: The Standard provides NO definition of what will happen. That's pretty much what the standard has always said. > I also think some machines that were around may have had natural > behavior that couldn't quite fit that model, I seem to remember some > that trapped in a way that didn't lead to calling a signal handler. > > Given the current definition, some implementations have developed > optimizations that also don't map into that model, which they use to > speed up well behaved code. One such optimization would be that the > value of x + a > x + b is the same as a > b, and the expression x > doesn't need to be computed at all (as long as any side effects are > performed). This does not hold in the presence of overflow. How does that not fit into that model? If neither x+a nor x+b overflows, then x+a > x+b is equivalent to a > b. If either x+a or x+b overflows (assuming signed addition), then the behavior is undefined, and treating it as equivalent to a > b is perfectly legitimate. (The part about raising an implementation-defined signal applies only to conversion to a signed type, and was added in C99. The rules for conversion differ from the rules for arithmetic operations.) [...] -- Keith Thompson (The_Other_Keith) kst-u@mib.org Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */