Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++26: Erroneous behaviour

sandordargo.com

Post reply on HN
Print view View original

81–90 of 103 posts

Re: C++26: Erroneous behaviour

#81

Post by quotemstr »

aw1621107 wrote: post #25
quotemstr wrote: post #6

Earlier quoted context omitted.

> As a long time user of C++, I want to propose a question: do we think C++ will ever reach a point where it is significantly ergonomic and safe enough to use (in comparison to e.g. Python or Rust) via adding new features? Memory safety semantics aside (needed and will be disruptive, even if done gradually) --- You could get 80% of the way to ergonomic parity via a 1:1 re-syntaxing, just like Reason (new syntax for O…

> You can address a lot of the pain points by making an alternative, clean-looking "modern" syntax that, because it's actually the same language as C++, would have perfect interoperability. Sounds like Herb Sutter's cpp2/cppfront: https://github.com/hsutter/cppfront

Sadly, Sutter disagrees philosophically with making locals const by default, and I think doing so is table stakes: https://github.com/hsutter/cppfront/wiki/Design-note%3A-cons...

I mean, c'mon

> Show that in today's C++ guidance literature we already teach C++ programmers to make local variables const, and link to a few examples of such guidance (which will contain more details, including examples of problems that the advice avoids). That will start to make the case. If you can do that, feel free to open a "suggestion" issue about it!

That "C++ guidance literature" is called the Rust book. Const by default won.

Re: C++26: Erroneous behaviour

#82

Post by TuxSH »

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 initializes all unknown-value stack variables with 0xFEFEFEFE(...). This is usually an invalid fp value, invalid offset and invalid virtual address, allowing crashes to happen. This is a good thing.

Regarding performance, there is an attribute to opt out (both for the standard C++26 feature and the GCC option that is a subset of it)

Re: C++26: Erroneous behaviour

#83

Post by halfcat »

tempodox wrote: post #68
saghm wrote: post #9

Earlier quoted context omitted.

> do we think C++ will ever reach a point where it is significantly ergonomic and safe enough to use (in comparison to e.g. Python or Rust) via adding new features? This is an interesting perspective to me, because my view as someone who's been using Rust since close to 1.0 and hasn't done much more than dabbled in C++ over the years is basically the opposite. My (admittedly limited) understanding is that this has ne…

With C++ I can use Qt to make a GUI app that builds and runs on macOS, Linux, and Windows. Is there anything even close to that for Rust?

There’s egui [0] [1] which, being immediate mode, simplifies state management quite a bit. Runs on Mac, Linux, Windows, Web, and mobile.

[0] https://github.com/emilk/egui

[1] https://www.egui.rs/

Re: C++26: Erroneous behaviour

#84

Post by bluGill »

AnimalMuppet wrote: post #15
bluGill wrote: post #5

Earlier quoted context omitted.

That doesn't matter - it cost a billion dollars to write the current project I work on. There is no way I can ask for that much to rewrite it all in whatever. Thus we are stuck on c++ which was the best choice 15 years ago. Anything that makes new code easier to write is great help. sure we are looking at options - but rust and c++ don't interoperate well (c api is too limiting). D was looking interesting for a while…

60 million dollars a year in development for 15 years? What are you working on?

The billion was the rewrite, not continued maintenance. So billion over around 7-10 years (the early releases greatly lacked features but some of the features had maintenance work done and additional features added while other parts of the rewrite were in progress). But yes at least 200 developers have worked on the project every year, not to mention a lot of testers and such. this is normal for all the different companies I've worked at.

you can perhaps guess based on my comment history but I'm not supposed to state directly.

Re: C++26: Erroneous behaviour

#85

Post by pwdisswordfishz »

tialaramex wrote: post #79
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…

Ignoring performance considerations, which I'm happy to address separately if people care, the options were: #1 Require initialization (like many modern languages). Makes sense. But now your existing C++ doesn't even compile so that's a hard "No" from the committee. #2 Status quo, evaluating uninitialized variables is Undefined Behaviour. We cannot diagnose this reliably, any attempt will be Best Effort and several v…

The distinction between #3 and #4 does not matter in practice: "I have learned to use variable initializers, that's why there isn't one present". As soon as you make it reliable, people will start to rely on it and it will become entrenched.

Re: C++26: Erroneous behaviour

#86

Post by bluGill »

Yoric wrote: post #57
paulddraper wrote: post #19

Earlier quoted context omitted.

Chrome doesn’t fit those figures exactly but is close.

...and some components are being rewritten in Rust, if I recall.

Some small parts are. After several decades those small parts will add up but for now rust is almost nothing overall.

Re: C++26: Erroneous behaviour

#87

Post by halfcat »

kachapopopow wrote: post #49
jb1991 wrote: post #47

Earlier quoted context omitted.

Writing cross-platform code between CPU and GPU, a very common occurrence, is certainly one reason to use C++.

gpu-rs (hopefully) will do it better including all the sub-projects around it.

> rust does quite literally, everything better

> (hopefully) will do it better

So, not quite literally everything

Re: C++26: Erroneous behaviour

#88

Post by tialaramex »

aw1621107 wrote: post #67
LoganDark wrote: post #39

Earlier quoted context omitted.

Yes, I got that much, but I'm curious to see what happened. Do you have any links about it?

The interpretation is probably up for some debate especially since meeting details are not public, but some relevant links are: - The P3390R0 Safe C++ proposal and the related vote in the 2024-11 Wrocław meeting: https://github.com/cplusplus/papers/issues/2045 - The adoption of the paper P3466 R1 (Re)affirm design principles for future C++ evolution at the same meeting, which contains language which can be interprete…

P3466 resulted in a new Standing Document for the committee. SD-10 https://isocpp.org/std/standing-documents/sd-10-language-evo...

The idea in this document was to write down "principles" of the C++ language without regard to annoying facts which might put those principles in doubt.

Re: C++26: Erroneous behaviour

#89

Post by galangalalgol »

wolvesechoes wrote: post #65
quamserena wrote: post #51

Earlier quoted context omitted.

Rust’s borrow checker has been mathematically verified to be always sound.[0] These are edge case implementation bugs that user code is unlikely to touch. I have never had a soundness hole/segfault from safe Rust, and I am not aware of any code in the wild which stumbled into one of these soundness holes either. The main bug is [1], which is very contrived lifetime shenanigans that wouldn't appear in real code. Some…

So it is not 100% contrary to some bombastic claims floating around.

I don't feel I was bombastic, simply ignorant. I knew there had been unsoundness bugs in the past, but I thought they had all been fixed at this point. I see why it is taking them so long to fix this one, but yes it is not 100%. I will rather say that I have had no segfaults from safe rust in the decade I've been using it, and that even after 35 years in c++ I still average a couple a month. Probably worse now because I'm rusty when I go back to use it for something. It could be argued I'm really bad at c++, and maybe that is true, but then maybe I shouldn't be using it, and should use rust instead, it allows me to get the same job done.

Re: C++26: Erroneous behaviour

#90

Post by steveklabnik »

dwattttt wrote: post #22
saghm wrote: post #21

Earlier quoted context omitted.

I think I might be getting confused about the point you're making here. To me, pre-existing knowledge and the decades-long legacy of C++ feel like much stronger arguments against changing anything in a breaking way compared to making breaking changes to improve the language. I do agree with you around a lot of the new features being introduced not feeling super necessary, but I'm guessing that the stance of people in…

The biggest question I have around the viability of breaking changes in C++ is whether you can compile some code with a newer breaking standard, some with an older standard, and link them. Headers would be a problem given their text inclusion in multiple translation units, but it's not insurmountable; you're currently limited to the oldest standard a header is included into, and under a new standard that breaks compa…

There was a proposal for “epochs” (the feature that rust calls “editions” now) but they were effectively rejected by the committee. Not permanently, but there’s some questions that need to be addressed that they initial proposers aren’t interested in following up on, in my understanding.
Post reply on HN