You’ve never had an integer overflow? You’ve never dereferenced a null pointer?

I suspect every C programmer causes undefined behavior in their first 50 hours of writing C.

It's quite safe to say that every hand-off between code written by different developers can exercise UB in a few different ways.

> I cannot say I have ever written anything that ran into or caused undefined behavior.

But how would you know? :)

These days it is not quite unknowable, if you always runs your programs with the address sanitizer and UB sanitizer on. They aren't perfect but they would provide a pretty good indicator of whether there was any UB or not.

I wouldn't call some cases of UB like overflowing a signed int or running into a dangling reference "actively pushing the compiler". I'm having a hard time believing you didn't ever run into these or similar issues having "programmed for a long time".

For other cases (e.g. aliasing, alignment), I'd agree that one is rather safe as long as the dangerous tools (e.g. reinterpret_cast) are not used.

It's the same for me. Well, I've hit segfaults when dereferencing invalid pointers (including NULL). I've had some surprises with shifting and signed integers as well. But I'm not sure that I've hit strange behaviours late in development. All that stuff is just, oh, I got that wrong, let's fix it. At most - oh I hadn't known that detail about signed arithmetic.

If the compiler removes an important check or branch like in the post, and it isn't noticed in development chances are the code is dead, or not that important. And I'm not saying this to downplay the risks. A big risk is that a particular instance of UB is exploited only by a newer version of the compiler, after the code is already finished. But in general, the language remains a remarkably productive one that lets me get very close to where I want to be, very quickly.

Is it possible to know for sure that it's all correct and will continue to be correct with newer compilers? Not 100%, but maybe it's still a good tradeoff in some environments.

> I cannot say I have ever written anything that ran into or caused undefined behavior. And I have programmed for a long time.

Assuming you're working with C or C++, you've never:

- Dereferenced a pointer? - written a loop with a signed index? - Accessed an index in an array or a vector? - Used a variable? - Used an optimising compiler?

Compilers use undefined behaviour in all of the above scenarios as much as possible, and to do what you likely intended. That's not to say _all_ UB is as reasonable, but a significant amount of what you write relies on some implicit assumptions about UB for a compiler to output reasonable code.

I think they meant "never written UB"? Which would still be a bold claim, much like "I never write bugs" (only features :P).

Compilers use reasoning based on UB to optimize and simplify code. But that's not a complete argument why it's highly likely that a given code exhibits UB at run time.

In a similar vein to "dereferenced a pointer", "null check on a pointer" is one of those things that often gets optimized out without the developer realizing it.

> I cannot say I have ever written anything that ran into or caused undefined behavior. And I have programmed for a long time.

If during that long time you were writing C or C++, it's very likely that you did but you may not have attributed the bugs you were fixing to Undefined Behavior. You may have considered them either to be your bugs or "compiler bugs that you worked around."

I have written in C/C++ and gotten my fair share of null pointers or broken things but all related to logic or my own programming errors. But to me those are just that logic errors or my own crappy code errors.

Back when I worked on VAX/Alpha (I am old) I absolutely had to get down and read assembly/binary to figure out the compiler was doing what I thought. And in some cases had to work around compiler bugs.

But for most of the more recent things I have written I just have not run into these types of errors. I am really boring or I write code that is boring ha.

It is fascinating that people study this stuff and interesting to read about, I just do not run into it.

> I cannot say I have ever written anything that ran into or caused undefined behavior. And I have programmed for a long time.

Perhaps this is true, or perhaps you are just unaware of the undefined behavior you have relied on.

What I can say for sure, is that all of the non-trivial C++ programs written by a large team which I have worked on in my career have invoked some undefined behavior. Usually, the compiler does do "the right thing" despite the error, but sometimes it blows up in our face, and causes incredibly hard to debug bugs, such as a pointer appearing to simultaneously point to two different addresses, because an array was declared as two different sizes in two different translation units.

Even when I spot the instances of undefined behavior, it's often hard to convince other developers that, although this seems to behave correctly now, it could break in unexpected, hard to debug ways at any time in the future.