Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: the language (and the role of Undefined Behavior therein) Date: Fri, 21 Aug 2015 18:34:08 -0700 Organization: None to speak of Lines: 76 Message-ID: References: <5yhkw.397413$il4.43434@fx06.am4> <5492c298.300765@news.xs4all.nl> <90183436-b839-4ee9-a3ed-a9eab341e847@googlegroups.com> <_MQAx.4834$IB7.2230@fx07.iad> <896d7bb0-72f3-4905-847e-8f6b6246cfc0@googlegroups.com> <55D4E2C9.8030109@verizon.net> <430b14cb-c335-4e54-94c5-d1076a2142fe@googlegroups.com> <55D51DE6.6070606@verizon.net> <75e8b3e2-4171-40bf-9e2d-c3c132272dec@googlegroups.com> <1f86d431-4ab2-447e-830b-5878781225fc@googlegroups.com> <044f1f29-894c-46c1-9ff2-61ba5191c3f5@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="15005"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+QS+AqiD/FE62s3bl0A1Wg" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:5dsRi7cURoJAeRLsPmZs75STsSk= sha1:B+1uZ9+2nJcB6FtyjktmZwy/zYw= Xref: csiph.com comp.lang.c:67971 supercat@casperkitty.com writes: > On Thursday, August 20, 2015 at 6:48:24 PM UTC-5, Keith Thompson wrote: >> I'm skeptical that such a change was made, but I'm more than willing to >> be convinced. Can you cite the added wording in C11 that says this? > > Hmm... upon doing some further research, it seems I may have been mistaken. > >> > By the mid 1980s, mainstream compilers for mainstream platforms had >> > pretty well established some de facto boundaries for the behaviors of >> > some actions where the standard imposed no requirements. Thus, by the >> > mid 1990s, programmers faced with the choice of writing nasty code to >> > avoid overflow, or less-nasty code to limit the effects, would >> > generally perceive no reason to favor the former unless their code >> > would need to run on some really obscure hardware. >> >> In the mind 1980s, there was no C standard. > > I would say that the 1978 publication of The C Programming Language, by Brian > W. Kernighan and Dennis M. Ritchie, established a C Standard. I don't know > exactly when the new parameter specification form entered mainstream use, but > it was certainly before the 1989 publication of the ANSI C Standard. I first > started programming with Turbo C in early 1988, and nearly all the code I > ever saw used the new form. Prototypes were invented in C++ and later added to C. They were first *officially* introduced by the 1989 ANSI standard, but they were undoubtedly implemented and used before that (just because they were *so much better* than old-style function declarations). There was also a tool called "ansi2knr" that would translate C code with prototypes to C code without prototypes, so you could use prototypes even if your compiler didn't yet support them. >> That sounds similar to SFINAE >> https://en.wikipedia.org/wiki/Substitution_failure_is_not_an_error >> but that applies only when a template expansion would cause a >> compile-time error; undefined behavior is not relevant. > > If evaluation of a compile-time constant in the course of a template > expansion would invoke Undefined Behavior (e.g. -1<<3), the Standard > mandates that the expansion be regarded as ill-formed, even if the > compiler's documentation would specify a behavior consistent with > yielding a constant (e.g. -8). [...] >> Certainly optimizers have simply gotten more clever over the years. >> I'm not aware of any sudden change of the kind you describe. > > Historically, most optimizers would perform transformations which would be > valid under some sort of execution model. [SNIP] > The hyper-modern philosophy is different, in that it makes it impossible to > define or constrain the effects of any sort of UB. I don't have a firm grasp > as to when and how the philosophy took hold, but it seems to have been > sometime around 2009. The "hyper-modern philosophy" is the one that's been implicit in the C standard since 1989. I haven't kept track of developments in optimization well enough to know how things have changed or when they've changed. But if your program has potential undefined behavior, I suggest that you need to fix the program. If you think that int n = INT_MAX; n ++; "should" set n to any particular value, that's not a conclusion that you can draw from the C standard. I do agree that compilers should do a better job of diagnosing such programs, especially when they take advantage of the presence of undefine behavior to perform "surprising" transformations. I don't see the point of catering to such code beyond that. -- 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"