Bjarne Stroustrup’s Plan for Bringing Safety to C++ (The New Stack)

The number of people who are happy if it's UB is roughly the same as the number of people who are happy with any implementation defined behaviour that meets the spec - they're already guaranteeing that y is in range.

The issue here is that people are bad at recognising when they've written buggy code; they don't believe that they've written something that's UB, since x >> y is not UB if y is in range, and unless you force them to spot their bug, they'll assume that it's fully defined, not implementation defined, and blame the compiler when what they've written does not do what they want.

You are describing Rust community, not C/C++ community. That's the main difference:

Sadly that sentence is not a sarcasm, but is what significant portion of the community actually expects. This idea:

is very actively rejected by significant proportion of C/C++ community. In their mind if they are writing “good program with UB” then it's the compiler fault if it suddenly stops working. How the hell compiler is supposed to understand which UB is “bad” and which UB is “good” and how can it produce “fairy dust” which would “respect “the principle of least susrprise””… that is not their problem.

Changing UB definition without addressing the problem of said sub-community wouldn't lead to safer code. If you lie to the compiler then you shouldn't expect that compiler would work reliably!

This, seemingly simple, idea is not accepted by C/C++ community and that is why C and C++ are not fixable.

The problem here is that if the compiler starts generating diagnostics for UB, there will be a lot of them; you can buy tools like PVS-Studio, PC Lint and more that generate diagnostics for some UB, but most people don't bother because the work needed to silence believed false positives and get the diagnostic spam down to a reasonable level.

Worse, the C++ standard (representative of what the C++ community cares about) contains plenty of instances of undefined behaviour where "no diagnostic is required", along with the terrifying phrase "ill-formed; no diagnostic required". If you simply required diagnostics for all the cases where a program is "ill-formed", has "undefined behaviour" or has "unspecified behaviour", then you'd have a huge pile of diagnostics to wade through, many of which are currently a non-issue.

And this then leads you straight back to the social problem; because C++ has said that it trusts programmers to not write ill-formed programs, or programs with UB, while programmers tend to assume that something that the compiler accepts is well-defined, you'll have problems with programmers insisting that the compiler is being overzealous by complaining. You can see this for yourself if you buy something like PVS-Studio and try to make your codebase warning-free against that tool; you will get huge pushback on everything it picks up, and will end up having to make use of things like PVS-Studio's ability to track which warnings are new, and not complain about your 400K lines of legacy.

Your compiler is part of your platform. If you don't want the meaning of implementation defined behaviour to change on the same hardware, stick to the same compiler.

Otherwise, you have the compilers able to change the implementation definition between versions, which puts you back in the place you don't want - dealing with Gödel's incompleteness theorem as it applies to the mathematical model of the language. And the language model is maths, and cannot be 100% defined behaviour without tripping over Rice's Theorem, where you cannot express perfectly reasonable concepts in the language because they are not 100% defined.

This is why a language like Rust needs "unsafe"; there are useful programs that cannot be expressed in any 100% defined language, and if you want those programs to be in your language, you need to allow me to go to a place where UB is possible, and be careful not to trip over it.

That mode is also implemented by most compilers. Usually the mode is triggered with -O0, although MSVC calls it /Od. But that doesn't satisfy C/C++ developers either.

Yup. And that attitude is quite real and fundamentally unfixable problem of C/C++. If you couldn't clean your community of people who sprout such nonsense then you can not achieve any semblance of safety. It just wouldn't work.

You program may only be safe if all components of it adhere to the same rules and if some members of the community think that rules are written to be broken… then that's it. Your changes to the spec may only do very martinal improvements.

Just how is compiler supposed to know whether your code was depending on platform-specific behaviour? How? By replacing two hundred UBs with ten thousand rules which explain how to transform C code into machine code and which are different for different CPUs?

Why do you believe that people who couldn't remember the list of two hundred UBs would rememeber two hundred thousand rules which explain how compiler may convert your code into a machine code?

void foo(int x) {
  int y = x;
}

You claims about CPUs do not match my experience of CPU cores from Arm or from Intel. IME, when something is said to be "undefined", it's because the CPU core does not reach a stable state within a clock cycle. For things that the manufacturer does not want to commit to, I more normally see them saying that the behaviour is defined by the microarchitectural stepping, not that it's undefined.

This is pretty much the same distinction as undefined behaviour versus implementation defined behaviour in compilers.

One example of undefined behavior is “cross-modifying code”. From Intel's errata: Software using unsynchronized XMC to modify the instruction byte stream of a processor can see unexpected instruction execution from the processor that is executing the modified code.

In reality if you don't follow certain protocols then you may achieve pretty crazy results including execution of instructions that are neither in old code stream nor in new code stream.

But yes, true “unrestricted UB” is pretty limited in hardware, and it's usually not an expected behavior.

Hardware us the same. Processors today are, in reality, complicated JIT-compilers thus we have things like these. They are not rare.

The cultural value of "unsafe" in Rust is that where your Rust code has no "unsafe" in it, all code either fails to compile, or has fully defined behaviour. This means that safe Rust is not as performant as C++ on certain problems, precisely because there's no lee-way to optimize differently for the hardware at hand.

This is a tradeoff; Rust says that "fully defined, less performant" is the right default, and that there should be an opt-in way to say that you're worrying about UB; C++ says that you should always be worrying about UB, and if you're not, you're holding the language wrong.

void foo(int x) {
  int y = x;
}

movabs $0x8000000000000000,%rcx
cmp    %rcx,%rdx
je     ...

cmp    $0x1,%rdx
jo     ...

dec    %rdx
jo     ...

  1   2    3
 79  54  104 llvm-mca-11 --mcpu=tigerlake
 80  54  104 llvm-mca-11 --mcpu=znver2 seq3.s
154 104  104 llvm-mca-11 --mcpu=tremont
154 104  104 llvm-mca-11 --mcpu=silvermont

	leaq	-1(%rdx), %rax
	cmpq	%rdx, %rax
	jg	...

 1    2    3    4
1.02 0.54 0.54 0.55 Rocket Lake
0.54 0.54 0.52 0.53 Zen3
1.19 1.03 1.03 1.03 Tremont
2.05 1.06 2.05 1.55 Silvermont
2.42 1.43 1.27 3.09 Bonnell

mov r9, LONG_MIN
cmp r9, r10
je ...

dec r10
jo ...

You may disagree with that step, but why are you sure that others would disagree with it, too?

When John Regehr to collect list of UBs which shouldn't be UBs the only result that he was able to achieve was to find out that literally no one agrees on anything.

Everyone have their pet peeves where compiler treats as UB something that they think shouldn't be UB and yet almost everyone have ideas about which optimizations are indispensable — and these optimizations require certain things to be UBs!

Some, like Wol here, are even advocating replacing one language with 200 UBs with 2²⁰⁰ languages with random assortiment of UBs (that's what “I just need this to become a user-defined flag” means, right?) and even say this would, somehow, make things more secure… and no, they are not joking!

The fact that they believe anything reliable may be achieved in this madness is the real C/C++ disease. Bazillion of UBs and unpredictable outcome of using the compiler are symptoms, the real disease is that desire to ear the cake and have it, too.

Rust never had it, it was concentrating on the idea that there are some rules that are supposed to be followed and there are process which makes it possible to change it, but as long as rules are there they shouldn't be ignored. Can you imagine something like this part: “some operation” is always Undefined Behavior. No you can't do it. No you're not special. to be enthusiastically embraced by C/C++ community without significant number of participants to declare that, yes, they are special, and yes, they would ignore rules, and yet it's compiler fault to produce incorrect program?

Rust tries to reduce number of UBs as much as possible, but that's, actually, the second step. The first one is firm assertion that community takes the full responsibility for active enforcement of the few remaining ones.

And, sadly, I don't foresee C/C++ community to accept that responsibility. They are all “too special” to accept it.