The problem is that a lot of the flexibility introduced by UB doesn't serve the developer.

Take signed integer overflow, for example. Making it UB might've made sense in the 1970s when PDP-1 owners would've started a fight over having to do an expensive check on every single addition. But it's 2026 now. Everyone settled on two's complement, and with speculative execution the check is basically free anyways. Leaving it UB serves no practical purpose, other than letting the compiler developer skip having to add a check for obscure weird legacy architectures. Literally all it does is serve as a footgun allowing over-eager optimizations to blow up your program.

Although often a source of bugs, C's low-level memory management is indeed a great source of flexibility with lots of useful applications. It's all the other weird little UB things which are the problem. As the article title already states: writing C means you are constantly making use of UB without even realizing it - and that's a problem.

▲ jstimpfle 3 minutes ago | parent | next [-]

That's completely besides the point. UB on signed overflow is not at all related to C flexibility. It is a detail of the spec related to portability and performance. IIRC it is even required to make such trivial optimizations as turning

    for (int i = 0; i < n; i++) func(a[i]);

into

    for (Foo *p = a, *last = a + n; p < last; p++) func(p);

saving arithmetics and saving a register, on architectures where `int` is smaller than pointers. But there is also options like -fwrapv on GCC for example, allowing you to actually use signed overflow.

But again, unrelated to the point. You're just spitballing.

I only agree to the last part, there are many ways to accidentally introduce UB. It doesn't happen quite as dramatically often as there is FUD, but it's a regular part of C programming for even seasoned devs. Then again, in most cases UB doesn't manifest in actual bugs, and how else do I create software that actually works in practice, and that does what I want with the control that I need, without requiring me to make tons of weird dances and introduce unmaintainable boilerplate required by many other languages?

You can also run your code in ASAN in UBSAN nowadays, it will catch many or most of issues as they happen.

▲ ablob an hour ago | parent | prev | next [-]

If we're talking two's complement it's not undefined that is right. Having to emit checks though, that is where I beg to differ. A check is only useful if you want to actually change the behavior when it happens, otherwise it is useless. Furthermore, it might be "essentially free" from a branch prediction point, but low and behold caches exist. You would pollute both the instruction cache with those instructions _and_ the branch prediction cache. From this it doesn't follow at all, that there is no cost.

In the end small things do add up, and if you're adding many little things "because it doesn't cost much nowadays" you will end up with slow software and not have one specific bottleneck to look at. I do agree that having the option for checked operations is nice (see C#), but I have needed this behavior (branching on overflow) exactly once so far.

	▲	Xirdus 3 minutes ago \| parent [-]
		> A check is only useful if you want to actually change the behavior when it happens, otherwise it is useless. You almost always want to change the behavior to erroring out on overflow. The few cases where overflow really is intended and fine can be handled by explicit opt-out. And I refuse to buy the argument that "small things add up" in the world where we do string building and parsing every few microseconds. Checked math will have unnoticable impact compared to all the other things we do, in almost every type of program.

▲ saagarjha an hour ago | parent | prev [-]

Signed overflow checks are typically not free unfortunately they have a cost of about 5% or thereabouts