Discussion:
Undefined Behavior in 2017
Add Reply
Noob
2017-07-07 20:08:30 UTC
Reply
Permalink
Raw Message
Here's an interesting article about UB:
https://blog.regehr.org/archives/1520

Regards.
Noob
2017-07-08 23:40:53 UTC
Reply
Permalink
Raw Message
Post by Noob
https://blog.regehr.org/archives/1520
First author is John Regehr
https://en.wikipedia.org/wiki/John_Regehr

Second author is Pascal Cuoq, who works on Frama-C
https://en.wikipedia.org/wiki/Frama-C
(static analyzer for C written in Ocaml)

AFAIU, Frama-C may be used to *prove* correctness,
as in "adheres to the spec, and guaranteed UB-free".
http://frama-c.com/features.html

Regards.
Tim Rentsch
2017-07-10 19:45:14 UTC
Reply
Permalink
Raw Message
Post by Noob
https://blog.regehr.org/archives/1520
Thank you for the link. Very interesting.
Richard Bos
2017-07-13 19:17:56 UTC
Reply
Permalink
Raw Message
Post by Noob
https://blog.regehr.org/archives/1520
"from a world where almost every nontrivial C and C++ program executed a
continuous stream of UB" - what bollocks.

Richard
s***@casperkitty.com
2017-07-13 21:01:00 UTC
Reply
Permalink
Raw Message
Post by Richard Bos
"from a world where almost every nontrivial C and C++ program executed a
continuous stream of UB" - what bollocks.
With apologies to John Adams, the C Standard is suitable only for use by
implementers with good judgment and common sense, and is unsuitable for
use by any other. The authors made no effort to forbid every unreasonable
thing an implementation might choose to do, and would even allow a conforming
implementation could behave in arbitrary fashion when given anything
other than a contrived and useless program. Thus, it is literally impossible
for any program to do anything useful without relying upon behavioral
guarantees beyond those given by the Standard.
j***@verizon.net
2017-07-13 21:53:09 UTC
Reply
Permalink
Raw Message
Post by s***@casperkitty.com
Post by Richard Bos
"from a world where almost every nontrivial C and C++ program executed a
continuous stream of UB" - what bollocks.
With apologies to John Adams, the C Standard is suitable only for use by
implementers with good judgment and common sense, and is unsuitable for
use by any other.
Do you think a differently worded standard would make it possible to get a usable implementation of C out of an implementor who lacked good judgement? I sincerely doubt it.

I'll pass on the "common sense" issue - that's just a code phrase for "thinks the same way I do", and I certainly would not be particularly interested in an implementation produced by an implementor who thinks the same way you do.
s***@casperkitty.com
2017-07-13 23:03:10 UTC
Reply
Permalink
Raw Message
Post by j***@verizon.net
Do you think a differently worded standard would make it possible to get a usable implementation of C out of an implementor who lacked good judgement? I sincerely doubt it.
Any standard which tries to define a single category of conforming programs
that will run usefully on all conforming implementations must necessarily
be so loose in what it promises as to be useless for non-toy programs on
large platforms, or so severe in its platform requirements that smaller
platforms can't implement it.

On the other hand, a standard could define a category of Selectively
Conforming programs such that:

1. A conforming implementation given a Selectively Conforming program
would have two options:

a. Process it in defined fashion consistent with the Standard

b. Announce in Implementation-Defined fashion that it cannot do so
and discontinue processing without releasing nasal demons.

2. Almost anything that could be done by a C program today could be done
with a Selectively Conforming program, and

3. Most existing implementations would be readily adaptable to accept
Selectively Conforming programs whose requirements coincide with the
ways those implementations would "naturally" behave, at least when
invoked with proper compiler flags.

If e.g. a program contains a directive demanding that integer overflows
have no side-effects, and that the lower (int_size) bits of the result be
correct when stored or when coerced to smaller types, but not demanding
that temporary results be truncated, then given:

flag = x1*x2 > x3;

a conforming implementation would have two options:

1. Process the code so that it evaluates the expression correctly in
cases that don't overflow, and yields 0 or 1, chosen

2. Refuse to execute the program at all.

Common sense would suggest that quality implementations targeting silent-
wraparound two's-complement hardware should use the first option, but even
a deliberately-obtuse implementation would be able to do nothing worse than
refuse to run a program which it "should" be able to run without difficulty.
Post by j***@verizon.net
I'll pass on the "common sense" issue - that's just a code phrase for "thinks the same way I do", and I certainly would not be particularly interested in an implementation produced by an implementor who thinks the same way you do.
I judge an implementation's quality on factors like the ability to run code
written for other implementations, or the amount of code a programmer would
have to write to accomplish various tasks. While there are exceptions,
almost every program I've written has had two fundamental requirements:

1. When given valid data, produce correct output.

2. When given invalid data, don't launch nuclear missiles.

If a wide range of outputs would be equally acceptable in response to
invalid inputs, a compiler which is given the chance to select freely
among several ways of evaluating an expression may be able to produce
better code than a compiler which is fed either:

flag = (long long)x1*x2 > x3;

or

flag = (int)((unsigned)x1*x2) > x3;

If it doesn't matter whether the expression yields 0 or 1 in case of
overflow, why not let the compiler pick whichever would be more efficient?
Loading...