Undefined Behavior in C++: What Every Programmer Should Know and Fear - Fedor Pikus - CppCon 2023

cppcon.org/
---
Undefined Behavior in C++: What Every Programmer Should Know and Fear - Fedor Pikus - CppCon 2023
github.com/CppCon/CppCon2023
This talk is about You-Know-What, the thing in our programs we don’t mention by name.
What is this undefined behavior every C++ programmer has grown to fear? Just as importantly, what it isn’t? If it’s so scary, why is it allowed to exist in the language?
The aim of this talk is to approach undefined behavior rationally: without fear but with due caution. We will learn why the standard allows undefined behavior in the first place, what actually happens when a program does something the standard calls “undefined,” and why it must be taken seriously even when the program “works as-is.” As this is a practical talk, we will have live demos of programs with undefined behavior and sometimes unexpected outcomes (if you are very lucky, you might see demons fly out of the speaker’s nose). Also, as this is a practical talk, we will learn how to detect undefined behavior in one’s programs, and how to take advantage of the undefined behavior to gain better performance.
---
Fedor Pikus
Fedor G Pikus is a Technical Fellow and head of the Advanced Projects Team in Siemens Digital Industries Software. His responsibilities include planning the long-term technical direction of Calibre products, directing and training the engineers who work on these products, design, and architecture of the software, and researching new design and software technologies.
His earlier positions included a Chief Scientist at Mentor Graphics (acquired by Siemens Software), a Senior Software Engineer at Google, and a Chief Software Architect for Calibre PERC, LVS, and DFM at Mentor Graphics. He joined Mentor Graphics in 1998 when he made a switch from academic research in computational physics to the software industry.
Fedor is a recognized expert in high-performance computing and C++. He is the author of two books on C++ and software design, has presented his works at CPPNow, CPPCon, SD West, DesignCon, and in software development journals, and is also an O'Reilly author. Fedor has over 30 patents and over 100 papers and conference presentations on physics, EDA, software design, and C++ language.
---
Videos Filmed & Edited by Bash Films: www.BashFilms.com
CZcams Channel Managed by Digital Medium Ltd: events.digital-medium.co.uk
---
Registration for CppCon: cppcon.org/registration/
#cppcon #cppprogramming #cpp

[@robertolin4568]

This shows how awkward c++ has become. As a high level language, the only obvious way to prove or disprove undefined behavior exists before runtime is to "manually inspecting the assembly output." And people do that in every cppcon talk, completely giving up that fact that it should be a high level language. What an irony!

[@ArminHasitzka]

Love Fedor's unique presentation style, and very important talk to listen to for everyone!

[@dickheadrecs]

GCC “wait forever? you’re the boss!”

[@temdisponivel]

I don't think the compiler (current or future) would optimize the original g() to return true.

[@feisty-trog-12345]

In the example shown at

[@sjswitzer1]

The classic example of a contract that’s too expensive to validate is that a binary search must be given sorted data. Validating the ordering is as expensive as a linear search, making the binary search pointless.

[@gamekiller0123]

Isn't the first example wrong? If i is INT_MAX, then there is no undefined behavior because the else branch won't be taken. If I is any other value, then calling f is fine.

[@gfasterOS]

I'm still not convinced that making g never return false in the first example is a valid optimization.

[@LucasSantos-ji1zp]

The code at

[@johnmcleodvii]

I've written a line of code with undefined behavior that destroyed my hard disk twice. The second time I was single stepping through the code and went one line too far. Long = short * short without casts. So the 2 shorts could multiply to be too large for a short. Sometimes that would set the sign bit. Next step is to seek from the start of the file, when write some data. That hit the engineering sectors of the disk.

[@Kriby88]

Fedor is a fantastic speaker, always love to see talks from him!

[@AlfredoCorrea]

23:55

[@Roibarkan]

23:56

[@Bolpat]

23:30

[@djouze00]

This topic is always interesting! Thank you!!

[@paradox8425]

Great talk! UB effecting previous code and what happens with debugger was truly eye opening

[@n0ame1u1]

I still don't understand how the example with f and g is undefined behavior. As written, f is never called if i is INT_MAX, and f is valid for all other i, so there is no case in which UB happens. What am I missing?

[@Digrient]

Thanks for that talk, very interesting! I’m still not entirely clear though on why compilers don’t emit more warnings when they optimize away code based on the assumption of the absence of undefined behavior, when it in fact seems much more likely that the programmer has intended something else or made a mistake.

[@aniketbisht2823]

The first example does not have any UB whatsoever. No preconditions of any invoked expression is being violated. If "i" equals INT_MAX then g() returns true otherwise f() is invoked given that (i+1) will not overflow and hence a valid expression. The compiler knows that (i+1) is always greater than "i" (because signed integer overflow would mean UB), therefore, it simplifies call to f() to returning true. With that the invocation of g() is simplified to (i != INT_MAX).

[@austinsiu2351]

9:53