Skip to content
0:00 / 0:00

#undefinedbehavior#llvm#clang

CppCon 2016: Chandler Carruth “Garbage In, Garbage Out: Arguing about Undefined Behavior..."

CppCon

189K subscribers • 94 videos on Hallway • Conference channel

YouTube
  • Recommended by 5 people: 4 on Hacker News and 1 on Lobsters.
  • A classic. People kept recommending it from 2017 to 2023.
  • Presented by Chandler Carruth, LLVM developer
  • Linked in the descriptioncppcon/cppcon2016

Intermediate. Assumes working knowledge.

93K views10 years ago5 recommendations

Programming languagesSystems programmingC++Compilers and interpretersPerformance and optimization

Chandler Carruth explains the compiler perspective on undefined behavior in C and C++ and how it enables optimization.

CppCon.org — Presentation Slides, PDFs, Source Code and other presenter materials are available at: github.com/cppcon/cppcon2016 — There has been an overwhelming amount of tension in the programming world over the last year due to something that has become an expletive, a cursed and despised term, both obscene and profane: **undefined behavior**. All too often, this issue and the discussions surrounding it descend into unproductive territory without actually resolving anything. In this talk, I'm going to try something very bold. I will try to utterly and completely do away with the use of the term "undefined behavior" in these discussions. And I will unquestionably fail. But in the process of failing, I will outline a framework for understanding the actual root issues that the software industry faces here, and try to give constructive and clear paths forward, both for programmers and the programming language. And, with luck, I will avoid being joined on stage by any unruly nasal demons. — Chandler Carruth Google C++ Lead San Francisco Bay Area Chandler Carruth leads the Clang team at Google, building better diagnostics, tools, and more. Previously, he worked on several pieces of Google’s distributed build system. He makes guest appearances helping to maintain a few core C++ libraries across Google’s codebase, and is active in the LLVM and Clang open source communities. He received his M.S. and B.S. in Computer Science from Wake Forest University, but disavows all knowledge of the contents of his Master’s thesis. He is regularly found drinking Cherry Coke Zero in the daytime and pontificating over a single malt scotch in the evening. — Videos Filmed & Edited by Bash Films: BashFilms.com Work at Hudson River Trading (HRT): tinyurl.com/safxfctf

Why it's here

5 people recommend this, 2 dispute it

What people say. Recommended as an excellent explanation of why undefined behavior exists in C and C++ and how compilers use it for optimization.

Moments people linked to

kllrnohjon Hacker News • Recommends

On “A Usable C++ Dialect That Is Safe Against Memory Corruption”

The generally recommended thing for catching & fixing this is: link CppCon has also had a lot of great talks on UB and why it is what it is, such as link to this video

lyricaljokeon Hacker News • Recommends

On “Depressing and faintly terrifying days for the C standard [pdf]”

Chandler Carruth's talk on the subject was really useful for my own understanding of the reasoning behind UB: link to this video

Jokyon Hacker News • Recommends

On “Trip report: Fall ISO C++ standards meeting”

Actually I discourage my colleague to use unsigned especially because they can overflow. The problem with overflow is that most of the time it is a program bug if there is an overflow that wasn't intended. Using signed arithmetic means that you can actually trap on overflow and catch these bugs (using fuzzing for instance). Chandler explained it nicely in his CPPCon 2016 talk "Garbage In, Garbage Out: Arguing about Undefined Behavior...". I encourage to watch the full talk but here is one relevant example: link to this video And here he mentions how Google experimented with this internally: link to this video

moefhon Hacker News • Recommends

On “A Guide to Undefined Behavior in C and C++”

One man's "broken code produced by the compiler" is another man's "excellently optimized code by the compiler". Where to draw the line is not always clear, but here's a very clear-cut example1 where emitting a warning would be bad. If you don't want to watch the video, it's basically this: - the code technically contains undefined behavior, but it will never be actually triggered by the program - changing the code to remove undefined behavior forces the compiler to emit terrible code Making the compiler yell at the programmer in this case would be terrible, but it's clearly a consequence of what you're asking. 1 link to this video

ThisIs_MyNameon Lobsters • Recommends

Garbage In, Garbage Out: Arguing about Undefined Behavior...

crististmon Hacker News • Disputes

On “New things in clang land (5.0.0)”

link to this video Thank you very much. Maybe the defenders of idiotic compiler behaviour can go now and hide under a rock. As for the slide at link to this video Correct or incorrect programs are defined in terms of the language. With an underspecified language like C you get what you deserve: -O2 being a different language than -O0 I've seen enough of this video where incorrect programs are being equaled to undefined language behavior. I'll stop looking further.

Mathnerd314on Hacker News • Disputes

On “Falsehoods programmers believe about undefined behavior”

"goes into". link to this video You mean this slide of the Joker with title "Do I really look like the kind of language that would define its behavior?" As far as I can tell there is no reason LLVM couldn't compile a document like "On x86 division by zero throws a #DE exception. On ARM division by zero returns zero. On x86 shifting by more than 32 bits shifts by (cnt mod 32) bits. On ARM shifting by more than 32 bits clears all bits. ..." that specifies all undefined behavior. The current "nasal demons" behavior is preferred in the name of performance on some SPEC benchmarks that nobody was asking for, screwing OS writers and anyone who expected sane language semantics.

u/xeowin r/ProgrammingLanguages • Mentions

On “Making all divisions slower to fix a bug in 0.000000000000000000542% of cases”

This whole talk is amazing, but especially this part is relevant: [CppCon 2016: Chandler Carruth "Garbage In, Garbage Out: Arguing about Undefined Behavior..." \time 39:19\](link to this video
12View on Reddit

pjmlpon Hacker News • Mentions

On “Alpine Edge has switched to libressl”

I very much doubt it, as it goes against the C culture of micro-optimize each code line as it is written, without any feedback from a profiler because "the coder knows best!". Since I know C (1992), I have seen quite a few times people write code to go fast as they can and apply compiler optimization tricks for use cases where it hardly matters. Also many of the issues regarding UB go back to the early ANSI C days, when it was the wild west of C dialects outside UNIX and no vendor wanted to give up on their own extensions. As for C and C++ compiler writers view on UB: link to this video

tynorfon Hacker News • Mentions

On “Let's Destroy C”

I haven't actually watched it in a while, but are you referencing this talk by Chandler Carruth? link to this video

monsecchrison Hacker News • Mentions

On “Almost Always Unsigned”

Signed integer overflow causing undefined behaviour allows the compiler to make significantly better optimisations. Here is Chandler Carruth, and clang developer, talking about it: link to this video

xscotton Hacker News • Mentions

On “How I think about C99 strict aliasing rules”

…y promote it to use register RAX as an index without any other shenanigans to deal with 32 bit overflow. RAX is a 64 bit register for integers or pointers. There are reasons why this might be advantageous over using EAX, which is the name for the low 32 bits of RAX. It's very possible that bonzini is referring to the example in the following link: link to this video Back to your overall point though, you're right that there's frequently an advantage to having your bulk data use smaller data types. It's better for caching and memory bandwidth, and it opens up more possibilities for parallelization with SIMD or GPU magic. However, it's really a false economy for things like loop indices. It doesn't matte…

obi1kenobion Hacker News • Mentions

On “Falsehoods programmers believe about undefined behavior”

Suggestions like this are unfortunately quite infeasible (they fall under the hat of "define all the behaviors"), and the talk I linked in the post goes into why: link to this video (I'm the post's author.)

xscotton Hacker News • Mentions

On “Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022”

…st adding new UB to Rust 4. So really, either Rust is significantly slower than C because Rust doesn't have the UB you're criticizing, or C could be a cleaner language without compromising on speed and the compiler writers and standards committees are wrong. You choose, but both options are considered heresy. 0 link 1 link 2 link 3 link to this video 4 link…

_gabe_on Hacker News • Mentions

On “Was Rust Worth It?”

> Thus, the compiler theoretically has the liberty to emit whatever it wants for this program. In theory, sure. In practice, what does it do? We can look and see.012 (I don't know of any compiler that emits garbage in the example you listed). For some reason, there's this sentiment that's arisen that treats undefined behavior as some sort of bugaboo that's capable of anything and everything (including summoning nasal demons). Here's a question that I can't find an answer to. Is machine code well-defined (as in, can it contain undefined behavior)? If the answer is yes, then all Rust programs can also contain undefined behavior, because they eventually turn into machine code after all. I…

atiedebeeon Hacker News • Mentions

On “What every compiler writer should know about programmers (Anton Ertl, 2015) [pdf]”

ISO C99 actually defines multiple types of deviating behaviour. What you're describing is closer to implementation-defined behaviour than anything else. The three behaviours relevant in this discussion, from section 3.4: 3.4.1 implementation-defined behavior unspecified behavior where each implementation documents how the choice is made EXAMPLE An example of implementation-defined behavior is the propagation of the high-order bit when a signed integer is shifted right. 3.4.3 undefined behavior behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements Possible undefined behavior ranges from ignoring t…