Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| Newsgroups | comp.lang.c |
|---|---|
| Date | 2015-08-21 01:32 -0700 |
| References | (17 earlier) <55D51DE6.6070606@verizon.net> <75e8b3e2-4171-40bf-9e2d-c3c132272dec@googlegroups.com> <ln1tex3gd3.fsf@kst-u.example.com> <1f86d431-4ab2-447e-830b-5878781225fc@googlegroups.com> <lnsi7d1n7c.fsf@kst-u.example.com> |
| Message-ID | <044f1f29-894c-46c1-9ff2-61ba5191c3f5@googlegroups.com> (permalink) |
| Subject | Re: the language (and the role of Undefined Behavior therein) |
| From | supercat@casperkitty.com |
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.
> 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).
> I'm still skeptical that anything in particular happened in 2009, but
> I'll gladly believe you if you can offer some citation.
There wasn't an abrupt change in 2009, and indeed I didn't notice a real change
until this year, but articles from around 2009 suggest that's when people
started to take seriously the idea that if a particular inputs would cause
Undefined Behavior, a compiler should infer that such inputs will never occur.
I really don't know the history of what happened very well, since I only became
aware this year that popular compilers are starting to incorporate such logic.
> 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. For example, a compiler may behave
under an execution model where each variable of type "int" (including compiler
temporaries) may hold any mathematical integer, but would only be guaranteed to
read the exact number written if it's between -2147483648 and 2147483647. If
a variable is written with a number outside that range, each read may yield an
independent arbitrary value which is congruent to the value written mod
4294967296. Under such a model, given
int a=2147483647; a++; long long b=a; long c=a;
Variables b and c could both hold 2147483648 or both hold -2147483648, or could
independently hold any two values which were congruent to 2147483648 mod
4294967296. Such an execution model would allow the forms of loop optimization
which are cited as the reason overflow "needs" to be UB, but would have effects
that were constrained enough that dealing with them could often be much easier
than preventing overflow. The behavior of most compilers has historically been
consistent with such a model unless they expressly trapped overflow. Some
loop optimizations performed transforms which could have been valid if
variables happened to always read the number that was written (regardless of
whether it was within the range of the type), but didn't actually make
the variables always hold values within range of their type, but even in those
cases the consequence would be "Overflow may cause a loop to exit early--even
before the overflow actually occurs". Not wonderful behavior, but something
that can be dealt with.
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.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-08-18 16:19 -0700
Re: the language (and the role of Undefined Behavior therein) Richard Damon <Richard@Damon-Family.org> - 2015-08-18 21:15 -0400
Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-08-19 10:11 -0700
Re: the language (and the role of Undefined Behavior therein) Ike Naar <ike@iceland.freeshell.org> - 2015-08-19 19:58 +0000
Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-08-19 14:09 -0700
Re: the language (and the role of Undefined Behavior therein) James Kuyper <jameskuyper@verizon.net> - 2015-08-19 16:10 -0400
Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-08-19 16:01 -0700
Re: the language (and the role of Undefined Behavior therein) James Kuyper <jameskuyper@verizon.net> - 2015-08-19 20:23 -0400
Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-08-20 10:35 -0700
Re: the language (and the role of Undefined Behavior therein) Keith Thompson <kst-u@mib.org> - 2015-08-20 12:32 -0700
Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-08-20 13:31 -0700
Re: the language (and the role of Undefined Behavior therein) donalhambra@gmail.com - 2015-08-20 14:23 -0700
Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-08-20 16:13 -0700
Re: the language (and the role of Undefined Behavior therein) Keith Thompson <kst-u@mib.org> - 2015-08-20 17:48 -0700
Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-08-21 01:32 -0700
Re: the language (and the role of Undefined Behavior therein) Keith Thompson <kst-u@mib.org> - 2015-08-21 18:34 -0700
Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-08-21 22:11 -0700
Re: the language (and the role of Undefined Behavior therein) Richard Damon <Richard@Damon-Family.org> - 2015-08-22 09:41 -0400
Re: the language (and the role of Undefined Behavior therein) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-22 16:59 +0000
Re: the language (and the role of Undefined Behavior therein) James Kuyper <jameskuyper@verizon.net> - 2015-08-22 23:30 -0400
Re: the language (and the role of Undefined Behavior therein) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-24 03:36 +0000
Re: the language (and the role of Undefined Behavior therein) James Kuyper <jameskuyper@verizon.net> - 2015-08-24 00:25 -0400
Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-08-23 22:57 -0700
Re: the language (and the role of Undefined Behavior therein) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-24 19:49 +0000
Re: the language (and the role of Undefined Behavior therein) Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-06 14:43 -0700
Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-08-23 16:27 -0700
Re: the language (and the role of Undefined Behavior therein) Richard Damon <Richard@Damon-Family.org> - 2015-08-23 21:15 -0400
Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-08-23 20:18 -0700
Re: the language (and the role of Undefined Behavior therein) raltbos@xs4all.nl (Richard Bos) - 2015-08-22 14:37 +0000
Re: the language (and the role of Undefined Behavior therein) David Kleinecke <dkleinecke@gmail.com> - 2015-08-22 19:12 -0700
Re: the language (and the role of Undefined Behavior therein) James Kuyper <jameskuyper@verizon.net> - 2015-08-22 23:38 -0400
Re: the language (and the role of Undefined Behavior therein) David Kleinecke <dkleinecke@gmail.com> - 2015-08-23 20:01 -0700
Re: the language (and the role of Undefined Behavior therein) Keith Thompson <kst-u@mib.org> - 2015-08-23 21:56 -0700
Re: the language (and the role of Undefined Behavior therein) David Kleinecke <dkleinecke@gmail.com> - 2015-08-24 17:25 -0700
Re: the language (and the role of Undefined Behavior therein) Keith Thompson <kst-u@mib.org> - 2015-08-24 18:21 -0700
Re: the language (and the role of Undefined Behavior therein) James Kuyper <jameskuyper@verizon.net> - 2015-08-24 22:22 -0400
Re: the language (and the role of Undefined Behavior therein) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-25 14:31 +0000
Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-08-25 09:22 -0700
Re: the language (and the role of Undefined Behavior therein) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-25 18:55 +0000
Re: the language (and the role of Undefined Behavior therein) Keith Thompson <kst-u@mib.org> - 2015-08-25 12:33 -0700
Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-08-25 16:23 -0700
Re: the language (and the role of Undefined Behavior therein) James Kuyper <jameskuyper@verizon.net> - 2015-08-24 00:31 -0400
Re: the language (and the role of Undefined Behavior therein) Keith Thompson <kst-u@mib.org> - 2015-08-24 10:32 -0700
Re: the language (and the role of Undefined Behavior therein) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-22 23:54 -0700
Re: the language (and the role of Undefined Behavior therein) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-24 03:45 +0000
Re: the language (and the role of Undefined Behavior therein) Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-07 08:11 -0700
Re: the language (and the role of Undefined Behavior therein) Richard Damon <Richard@Damon-Family.org> - 2015-08-23 18:46 -0400
Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-08-23 19:04 -0700
Re: the language (and the role of Undefined Behavior therein) Richard Damon <Richard@Damon-Family.org> - 2015-08-23 23:40 -0400
Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-08-23 22:48 -0700
Re: the language (and the role of Undefined Behavior therein) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-24 00:38 -0700
Re: the language (and the role of Undefined Behavior therein) James Kuyper <jameskuyper@verizon.net> - 2015-08-18 21:22 -0400
Re: the language (and the role of Undefined Behavior therein) Ike Naar <ike@iceland.freeshell.org> - 2015-08-20 21:44 +0000
Re: the language (and the role of Undefined Behavior therein) supercat@casperkitty.com - 2015-08-20 16:48 -0700
Re: the language (and the role of Undefined Behavior therein) Philip Lantz <prl@canterey.us> - 2015-08-20 23:41 -0700
csiph-web