Some people also feel strongly about topics they are very familiar with 🙂. I have experienced my fair share of undefined behaviour in C++ and it has never been a pleasant experience.
If you had half the experience you claim to have, you’d know that code that triggers UB is broken code by definition, and represents a bug that you introduced.
It’s not the language’s fault that you added bugs to the code. UB is a red herring.
Sure, sometimes use of undefined behaviour works (…)
You missed the whole point of what I said.
By definition, UB does not work. It does not work because by design there is no behavior that should be expected. By design it’s up to the implementation to fill in the blanks, but as far as the language spec goes there is no behavior that should be expected.
Thus, code with UB is broken code, and if your PR relies on UB then you messed up.
Nevertheless, some implementations do use UB to add guardrails to typical problems. However, if you crash onto a guardrail, that does not mean you know how to drive. Do you get the point?
It’s not the language’s fault that you added bugs to the code.
Nobody’s perfect and time has shown multiple time that you can’t trust human beings with memory safety. I.e. the whole 70% of bugs being memory safety bugs thing. Adding bugs to the code isn’t the language’s fault, but you can’t blame a human being (even experts) to do it.
It is however the language’s fault to allow UB in the first place. And it’s possible to entirely avoid UB in (safe) Rust. So we’ve seen that the possibility of undefined behavior is not necessary for the vast major of programming. So I would definitely say it’s C and C++'s “fault” for allowing UB in the unrestricted way that it does.
Am I blaming those languages? Nah, it was a different time. We didn’t have the technology we have now. But going forward there’s no reason to use unsafe languages in greenfield projects. We should move forward with safe languages.
Nobody’s perfect and time has shown multiple time that you can’t trust human beings with memory safety.
That’s perfectly fine. That’s not a problem caused UB, or involving UB.
Again, UB is a red herring.
It is however the language’s fault to allow UB in the first place.
It really isn’t. Again, mindlessly parroting this doesn’t give any substance to this claim. Please try to think about it for a second. For starters, do you believe it would make any difference if the C or C++ standard defined how the language should handle dereferencing a null pointer? I mean, in some platforms NULL is a tombstone, but on specific platforms NULL actually points to a valid memory address. The standards purposely leave this as undefined. Why is that? Seriously, think about it for a second.
Am I blaming those languages? Nah, it was a different time.
It really isn’t. It’s a design choice that reflects the need to work with the widest possible range of platforms. The standards have already been updated with backwards-incompatible changes, but even the latest revisions purposely include UB.
I repeat: I see people mindlessly parroting nonsense about UB when they clearly have no idea what they’re talking about.
If you had half the experience you claim to have, you’d know that code that triggers UB is broken code by definition, and represents a bug that you introduced.
It’s not the language’s fault that you added bugs to the code. UB is a red herring.
You missed the whole point of what I said.
By definition, UB does not work. It does not work because by design there is no behavior that should be expected. By design it’s up to the implementation to fill in the blanks, but as far as the language spec goes there is no behavior that should be expected.
Thus, code with UB is broken code, and if your PR relies on UB then you messed up.
Nevertheless, some implementations do use UB to add guardrails to typical problems. However, if you crash onto a guardrail, that does not mean you know how to drive. Do you get the point?
Nobody’s perfect and time has shown multiple time that you can’t trust human beings with memory safety. I.e. the whole 70% of bugs being memory safety bugs thing. Adding bugs to the code isn’t the language’s fault, but you can’t blame a human being (even experts) to do it.
It is however the language’s fault to allow UB in the first place. And it’s possible to entirely avoid UB in (safe) Rust. So we’ve seen that the possibility of undefined behavior is not necessary for the vast major of programming. So I would definitely say it’s C and C++'s “fault” for allowing UB in the unrestricted way that it does.
Am I blaming those languages? Nah, it was a different time. We didn’t have the technology we have now. But going forward there’s no reason to use unsafe languages in greenfield projects. We should move forward with safe languages.
That’s perfectly fine. That’s not a problem caused UB, or involving UB.
Again, UB is a red herring.
It really isn’t. Again, mindlessly parroting this doesn’t give any substance to this claim. Please try to think about it for a second. For starters, do you believe it would make any difference if the C or C++ standard defined how the language should handle dereferencing a null pointer? I mean, in some platforms NULL is a tombstone, but on specific platforms NULL actually points to a valid memory address. The standards purposely leave this as undefined. Why is that? Seriously, think about it for a second.
It really isn’t. It’s a design choice that reflects the need to work with the widest possible range of platforms. The standards have already been updated with backwards-incompatible changes, but even the latest revisions purposely include UB.
I repeat: I see people mindlessly parroting nonsense about UB when they clearly have no idea what they’re talking about.