this post was submitted on 24 Dec 2023
18 points (84.6% liked)
C++
1786 readers
2 users here now
The center for all discussion and news regarding C++.
Rules
- Respect instance rules.
- Don't be a jerk.
- Please keep all posts related to C++.
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Should focus on getting rid of undefined behavior.
What problem do you believe is presented by undefined behavior?
It violates the principle of least surprise. You don't expect the compiler to delete your bounds checking etc.
The way c and c++ define and use UB is like finding an error at compile time and instead of reporting it, the compiler decides to exploit it.
It really doesn't. I recommend you get acquainted with what undefined behavior is, and how it's handled by developers.
By design, undefined behavior has a very specific purpose. Newbies are instructed to consider code that leads to undefined behavior as a bug they introduced. For decades compilers and static code analysis tools can detect and flag undefined behavior as errors in your code.
As I said before, sometimes it seems clueless developers parrot on about "undefined behavior" as some kind of gotcha although they clearly have no idea what they are talking about. Sometimes it sounds like they heard it somewhere and just mindlessly repeat it as if it meant something.
What are you talking about? Compilers can and do flag undefined behavior as errors. I recommend you read up on the documentation of any compiler.
Also, I don't think you fully understand the subject. For example, as an example, some compiler implementations leverage UB to add failsafes to production code such as preventing programs from crashing when, say, null pointers are dereferenced. We can waste everyone's time debating whether null pointers should be dereferenced, but what's not up for discussion is that, given the choice, professional teams prefer that their code doesn't crash in users' machine if it stumbles upon one of these errors.
And I recommend you read Chris Latter's essay on UB.
https://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html
Where he gives plenty of examples of UB resulting in the compiler optimizing away safety and introducing security vulnerabilities silently. In part 3 he discusses the efforts clang has made to improve on this.
He then went on to make Swift and says this: "Undefined behavior is the enemy of safety, and developer mistakes should be caught before software is in production."
and
"UB is an inseperable part of C programming, […] this is a depressing and faintly terrifying thing. The tooling built around the C family of languages helps make the situation less bad, but it is still pretty bad. The only solution is to move to new programming languages that dont inherit the problem of C."
That's the bit that those who parrot on abot UB get entirely wrong, and yet cling to it if it was something meaningful.
Let's make this absolutely clear: any code you write that triggers UB is a a bug you introduced. Your complains about UB boil down to blaming the language for bugs you created because you didn't knew what you were doing.
As you can configure compilers and static code analysis tools to flag UB as warnings or even errors, the discussion of using UB in your code is a discussion on incompetence. Complaining that a programming language purposely leaves out the specification of the behavior that broken code should have because you don't know what you're doing is the definition of a bad workman blaming his tools.
If you paid attention to the article you're quoting, you'd notice that even the author makes it quite clear that programs with UB only "appear to work". That boils down to the definition of UB, and the reason why every single developer in the world who had any intro to C or C++ experience knows quite well that UB means broken code. Why is it hard for you to understand this?