Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: gcc failure (optimised/non-optimised) Date: Mon, 24 Apr 2017 12:06:13 -0700 Organization: None to speak of Lines: 60 Message-ID: References: <58fb2265.5246218@news.xs4all.nl> <4QjLA.892339$fZ.804703@fx41.am4> <87pog1zsry.fsf@bsb.me.uk> <77cc9c5c-e09a-4551-ba78-6ba10ce4dcaf@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="b06baaefdd2d8c25f7a310fe1662b016"; logging-data="9719"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX185sXlLMKH+l3dyutD7OuJd" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:y9mYWWqjNMgYbBeUh43hrx3Lud4= sha1:I0su/50oQ2xtLooIDJ1p6GoNVBM= Xref: csiph.com comp.lang.c:108424 supercat@casperkitty.com writes: > On Monday, April 24, 2017 at 11:15:21 AM UTC-5, Ben Bacarisse wrote: >> I think it was the committee that made it undefined (who, I suppose, >> count as language designers too) but if we take K&R1 as the view of the >> language designers, they chose to make it a slight variation on >> "implementation defined": >> >> "The action taken on overflow or underflow depends on the machine at >> hand." (K&R 1st ed. page 38) And on page 185, in the "C Reference Manual" appendix: The handling of overflow and divide check in expression evaluation is machine-dependent. All existing implementations of C ignore integer overflows; treatment of division by 0, and all floating-point exceptions, varies between machines, and is usually adjustable by a library function. Which implies, I think, that INT_MAX + 1 should yield INT_MIN on a machine with 2's-complement arithmetic (assuming those names have their modern meanings). K&R1 says that the action depends on the machine, not on the compiler. The statement is not very specific, so it would be difficult to say that a compiler that generated code that behaves differently was non-conforming, but that seems to have been the intent. On the other hand, I might argue that the statement that "All existing implementations of C ignore integer overflows" implies that some future implementation might behave differently, perhaps treating signed integer overflow as a fatal run-time error. > Note that Undefined Behavior explicitly lists as one of the possible > outcomes "behaving during translation or program execution in a documented > manner characteristic of the environment". The Standard does not specify > in what cases quality implementations *should* behave in a such a fashion, > but it would seem curious that the authors would have mentioned it if they > did not expect that many implementations would behave in such fashion. The > grammatical construction does not indicate whether the sentence should be > interpreted as: > > - behaving in a fashion which an environment documents as a characteristic. > > - behaving in a fashion which is documented by the implementation and > happens to be characteristic of the environment (which may or may not > document it). > > Given the ambiguity, I would suggest that in cases where an environment > documents a characteristic behavior, any quality implementation whose > behavior would differ should document such difference. I would suggest that *the language changed*. The statement in K&R1 was superseded by ANSI C's statement that signed integer overflow has undefined behavior. K&R1 did not have the modern concept of "undefined behavior". This may have broken some existing code that depended on 2's-complement wraparound. Them's the breaks. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"