
Enumerating Core Undefined Behavior - luu
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1705r0.html
======
taneq
For years I've been growing steadily more worried about UB and its nebulous,
Heisenfootgun nature. I got a few paragraphs into this noble work, scrolled
down to check how much was yet to go, and decided to try reading the Rust book
again.

I mean, I'll stick with C/C++ for now. I can write 'good enough' code which
does what I expect and seems to be reliable. I just hate the feeling that
without spending a truly ungodly amount of time on it, even the best code is
peppered with unknown unknowns waiting to bite me at some critical moment.

~~~
pingyong
Is this really such a big deal mentally? Idealized there are only two
behaviors: Expected and unexpected. Whether that unexpected behavior is a
result of UB, or implementation defined behavior, or logic errors, or
unforeseen corner cases, doesn't in practice actually matter. Your computer
isn't actually any more likely to cause a nuclear explosion because it hit UB
than it is to do that because it hit some other kind of bug.

Of course reducing and any kind of bug class is a plus, Rust is great, but I
never had the feeling that my C++ code is more error prone than my Java or
Python code just because some things are completely UB. What actually happens
with UB is that the application crashes and/or data gets scrambled - I've yet
to see my PC to feel free to stand up and walk away just because it was
technically allowed to.

~~~
gpderetta
As someone that writes a lot of C++ and quite likes the language, I think it
is feasible, given a team of experienced c++ programmers and a good testing
infrastructure to write programs that trigger almost no UB for any reasonable
input.

What I worry about is the unreasonable (i.e. hostile) input.

~~~
dirtydroog
Really? Isn't is still the case that signed integer arithmetic can lead to UB?
Despite this, there's a push for Almost Always Int from the C++ powers-that-
be.

[https://stackoverflow.com/questions/16188263/is-signed-
integ...](https://stackoverflow.com/questions/16188263/is-signed-integer-
overflow-still-undefined-behavior-in-c)

~~~
shakna
C++20 specifies two's complement for signed integer arithmetic, like it was
already for unsigned, which means most (basically everything except -INT_MIN)
is now no longer UB.

[0] [http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2018/p090...](http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r4.html)

~~~
gpderetta
I believe the representation is no longer implementation defined, but signed
overflow is still UB.

~~~
tomnj
That’s correct, and it’s quoted in JF’s paper linked above: “ The main change
between [P0907r0] and the subsequent revision is to maintain undefined
behavior when signed integer overflow occurs, instead of defining wrapping
behavior.”

~~~
pingyong
>Status-quo If a signed operation would naturally produce a value that is not
within the range of the result type, the behavior is undefined. The author had
hoped to make this well-defined as wrapping (the operations produce the same
value bits as for the corresponding unsigned type), but WG21 had strong
resistance against this.

I really don't understand _why_ WG21 is against this, do you happen to have a
link to arguments against it? The only one I frequently see is that "it's
faster that way" with a link to godbolt where iterating with a 32-bit signed
integer on a 64-bit system is faster than iterating with a 32-bit unsigned
integer, because the compiler exploits UB here to ignore overflow. Which is of
course a completely useless example because simply using a correctly sized
integer for iteration, signed or unsigned, will always result in the fastest
most correct code.

I'm not aware of any other arguments against it.

~~~
tomnj
At least in the case of overflow, the article mentions a few arguments:

“”” This direction was motivated by:

Performance concerns, whereby defining the behavior prevents optimizers from
assuming that overflow never occurs; Implementation leeway for tools such as
sanitizers; Data from Google suggesting that over 90% of all overflow is a
bug, and defining wrapping behavior would not have solved the bug. “””

------
yaghmour
For those interested in the four examples of crazy undefined behavior, you can
see my tweet here:
[https://twitter.com/shafikyaghmour/status/114602835166622925...](https://twitter.com/shafikyaghmour/status/1146028351666229250)

Also there is an R1 version which hopefully will get discussed in the next
meeting here: [http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2019/p170...](http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2019/p1705r1.html)

------
mmmrk
I don't know why, but I immensely enjoyed the use of that single emoji in the
opening paragraph.

~~~
silasdavis
Agreed a nice splash of figurative colour in a somewhat arid document...

------
pjmlp
Good to see this going forward.

