Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Show key headers only | View raw
supercat@casperkitty.com writes:
> On Wednesday, August 19, 2015 at 7:23:08 PM UTC-5, James Kuyper wrote:
>> The laws of time and causality don't say that foo==32 has to cause bar()
>> to be executed - it's the C standard which says that; and it only says
>> it in contexts where the behavior is defined. When the behavior is
>> undefined, the standard revokes that requirement, so a compiler can
>> generate code (which behaves strictly according to the laws of time and
>> causality) to produce a result quite different from that one.
>
> I am well aware that C11 says that the fact that a program is "going to"
> perform Undefined Behavior makes execution undefined even before it is
> invoked.
C99 and C89/C90 say the same thing; there's been no substantial change
in the meaning of "undefined behavior". Or am I missing something?
> I don't think debating the terminology is helpful, though there is
> a point I'm not clear on: given
>
> #include <stdio.h>
> int main(void)
> {
> int ch;
> printf("DO NOT press any key!\n");
> ch = getchar();
> if (ch >= 32) return 1 << ch; else return 1 >> (ch - 32);
> }
>
> would execution be well-defined if the user doesn't hits a key before
> execution is halted by some means (SIGINT, "kill -9", removal of
> power, etc.)? If getchar() returns, there will be no defined
> execution path (and a compiler could probably recognize that pretty
> easily), and the language of C11 suggests that UB can time-travel
> before I/O, but there's no way the abstract machine could perform an
> invalid left-shift if getch() doesn't return a value greater than 31,
> nor an invalid right-shift if getch() doesn't return a value less than
> 32. Could a compiler move the UB before the getch() despite the data
> dependency?
The compiler does not "move the UB". It generates code consistent
with the possible range of *defined* behaviors. If the program
has undefined behavior, that range is unbounded, and the generated
code can do literally anything (any bounds are imposed by things
other than the C standard, like the capabilities of the underlying
hardware or the laws of physics).
The behavior of the above code is undefined in all circumstances.
The use of an input function muddies the waters a little bit, but
IMHO not significantly. Any program can be terminated by external
means at any time; doing so during an input operation is not special.
A compiler can re-order operations as long as the resulting behavior
is still conforming. If that re-ordering causes some seemingly later
operations to occur while earlier operations do not because someone
pulled the power plug, that's not a violation of the standard.
A compiler could, for example, recognize that the program's behavior is
always undefined, and reject the program with an error message to that
effect. Or it could generate code that attempts to make demons fly out
of hour nose before the "DO NOT press any key!" message is printed.
>> That would be odd, because currently, the amount of ugly and
>> inefficient code required to avoid undefined behavior is relatively
>> minor.
>
> The amount of ugly and inefficient code employed to avoid UB seems
> minor because a lot of code *doesn't* avoid it. Instead, a lot of
> code was written on the assumption that if every compiler released in
> the last 10+ years for a mainstream platform would behave acceptably,
> future compilers would continue to do so.
What exactly happened 10 years ago?
[...]
> Handling overflow in such fashion as to meet requirements cannot be
> done quickly nor easily on *all* platforms, but any non-obscure
> hardware platform built in the last 20 years would have no problem
> whatsoever performing some calculation that would meet requirements.
> Until recently, one could expect that any non-obscure platform, given
> the original source code, would perform such a calculation (likely the
> most efficient one) unless "trap on overflow" was explicitly
> requested.
>
> Even today, programmers can and do avoid the burden by using -wrapv,
> but doing so often imposes constraints on the compiler which are much
> tighter than what the programmer actually needs, and also creates the
> danger that the code which relies upon the -wrapv option might
> accidentally get compiled without it.
C states that arithmetic overflow has undefined behavior, but
provides no coherent mechanisms to reliably detect or avoid it.
C programmers tend to deal with that problem by ignoring it.
We tend to be lucky; most arithmetic operations *don't* overflow,
but we rarely attempt to guarantee that. This is IMHO a flaw in
the language.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
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"
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