I'm not sure what your point is. The Linux kernel is riddled with undefined behavior and billions are spent on finding, removing, or mitigating that.

One of the more pernicious problems is security checks written to detect underhanded violations of constraints being eliminated because the compiler doesn't recognize the underhandedness is possible.

In a past life, I depended on signed overflow to detect out of bounds memory allocations. That kind of stuff gets compiled away these days, you need to be cleverer to detect when the user is deliberately trying to invoke UB. And because the compiler doesn't believe in UB, there's the risk it's going to remove your detection logic.

Making signed overflow to be well defined would be so much better.

IIRC C++ just decided that signed numbers are two's complement and that's that. C could really use similar thing.

> IIRC C++ just decided that signed numbers are two's complement and that's that.

Signed integer overflow is still undefined in C++.

You are correct. I misremembered, it was just a proposal that was not taken into the spec.

No, it's taken into the spec. It affects unsigned <-> signed conversions and maybe other things. Not integer overflow though.

Ah. Makes sense as that’s relatively cheap to emulate by just doing conversion when loading and storing from memory, but allows the use of HW even in case of ones complement implementation.

"Managed" is a strong word - there's regular complaining about compiler optimizations, there was a string of vulnerabilities where null checks were optimized out because they were secretly UB, and there was a discussion just last week about how compilers were reordering certain patterns in unexpected ways: https://linuxplumbersconf.org/event/7/contributions/821/

Quoting from the abstract of that talk: "... preserving source-level dependencies through to the generated CPU instructions is achieved through a delicate balance of volatile casts, magic compiler flags and sheer luck. Wouldn't it be nice if we could do better?"

Obviously the most dangerous form of undefined behavior is not that which always crashes but that which for some unlikely inputs cases crashes.

I wonder what would happen if i put hand into fire. But I have never done it in my life, because it might cause 'undefined behaviour'.

In my years of working with C its always the 'look how smart I am code' causes issues.

Keep it clean and simple. Avoid complexity and fluff features of C. And you will not going to have deal with exotic bugs.

I am pretty sure your hand going in fire is pretty defined behavior

Is it though, for yourself/your body. Is putting hand into a fire something you experienced and internalized?

Of all the possible things that could happen to me, I am very confident that only a small subset could result, so it is pretty well defined. Nasal demons, for instance, are not on the menu.

We are really straying off actual point.

Why would you not actively avoid undefined behaviour and instead take risk.

Zeroing out variables, checking pointers coming from external modules etc. Not rallying on a compiler to resolve fancy stuff.

Like the example:

void contains_null_check(int P) { int dead = P; if (P == 0) return; P = 4; }

Leave declarations uninitialized or zeroed Check input. Work with data.

void contains_null_check(int P) { int dead; if (P == 0) return; int dead = P //work P = 4; }

This leaves less space for error/interpretation and IMHO it keeps code cleaner.

Any fancy optimizations should be used only for critical path and only when absolutely necessary.

No, but it is part of the spec