C++26: Erroneous behaviour • Hacker News Board

Re: C++26: Erroneous behaviour

#101

Post by kachapopopow » Tue, Sep 09, 2025, 12:49 AM UTC

jibal wrote: post #99

kachapopopow wrote: post #96

Earlier quoted context omitted.

as a language, yes, the eco-system is still young.

You wrote "I just don't see a reason to use c++ anymore when rust does quite literally, everything better." -- there are numerous obvious reasons to continue to use C++, including its mature ecosystem, and other reasons have been pointed out. You have been called out for dishonesty. Stop lying. I won't respond again.

"For prototyping, hacking, firmware and native interfacing though? c++ any time of the day." - literally gave reasons to continue to use c++.

I just don't see a reason to use c++ anymore (as a language).

There happy? Point being if I am starting a project, it's going to be rust because it's just plain better as long as it's something I actually care about and isn't related to breaking things or leveraging the fact that c++ is worse (in a good way) or I am already working with c++.

Re: C++26: Erroneous behaviour

#102

Post by wffurr » Tue, Sep 09, 2025, 2:34 PM UTC

Kranar wrote: post #31

wffurr wrote: post #27

Earlier quoted context omitted.

>> The committee are really letting the vision of a good C++ down by refusing to break backwards compatibility to fix core problems IIUC this is what Profiles are. It’s an opt in source file method to ban certain misfeatures and require certain other safe features.

Safety profiles don't exist and there are so many issues with them that it's unlikely they will ever get added to the language. For example, you mention how it's a method applied to a source file, but C++ doesn't have the concept of a source file, it only knows about translation units. But then the problem becomes where exactly do you opt-in to this feature? If you do it in a header file then this can result in a fun…

There's a new attempt at safety profiles. I'm not enough of an expert or read in enough on this proposal to answer your detailed questions, but there's a lot of words by Sutter and Stroustrop on the proposals:

Stroustrop, 2023 presentation: https://open-std.org/JTC1/SC22/WG21/docs/papers/2023/p2816r0...

Sutter, 2025 committee paper: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p30...

Sutter, 2024 blog post: https://herbsutter.com/2024/03/11/safety-in-context/

Re: C++26: Erroneous behaviour

#103

Post by pwdisswordfishz » Tue, Sep 09, 2025, 2:53 PM UTC

TuxSH wrote: post #82

pwdisswordfishz wrote: post #77

Why bother with this category? The code exercising it is buggy either way, regardless of whether the behaviour is specified or not, and having a fixed definition may constrain implementations and negatively impact performance. And if that "erroneous" definition comes with stability guarantees, then you might not even bother calling it "erroneous" at all, because then it's going to be as toothless as declaring any giv…

> Why bother with this category? The code exercising it is buggy either way Because it is an actual security vulnerability if you cross privilege boundaries (infoleaks/(K)ASLR bypass, etc.), and one people often miss at that. Say you write: struct { long long a; char b; } foo; foo.a = 0; foo.b = 1; return foo; You end up leaking 7 stack bytes here (due to padding). GCC's `-ftrivial-auto-var-init=pattern` currently in…

How does it prevent security vulnerabilities when instead of being undefined entirely, the behaviour is defined to be wrong? This is the "chug along at all costs" mentality that PHP has been slowly and painfully growing out of.

`-ftrivial-auto-var-init=pattern` doesn't need "erroneous behaviour" in the standard at all. In fact, it may outright conflict with it, if for example the standard defines that the compiler must initialize variables to zero instead of your chosen pattern in case of "erroneous behaviour".

"Erroneous behaviour" is a superfluous concept that exists only to allow the committee to pat themselves on the back and say "See? We no longer have undefined behaviour!".