7 ms·

C++26: Erroneous behaviour

52 points by todsacerdoti 1y ago

gblargg 1y ago
> It’s well-defined, yet incorrect behaviour that compilers are recommended to diagnose. Is recommended enough?! Well, with the growing focus on safety, you can rest assured that an implementation that wouldn’t diagnose erroneous behaviour would be soon out of the game. Is this to cover cases that would be hard/costly to detect? For example you pass the address of an uninitialized variable to a function in another source file that might read or just write to it, but the compiler can't know.
- bluGill 1y ago
  Right. The compiler needs to diagnose where it can but the are many cases it cannot be sure.
ratmeadow 1y ago
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? I've used C++ for so long and I'm a good way into thinking that the language is just over. It missed its mark because of backwards compatibility with fundamental language flaws. I think we can continue to add features - which are usually decent ideas given the context, kudos to the authors for the effort - but the language will decline faster than it can be fixed. Furthermore, the language seems to be continually becoming harder to implement, support, and write due to the constant feature addition and increase in semantic interconnectivity. To me it's almost mostly a theoretical exercise to add features at this point: practically we end up with oddly specced features which mostly work but are fundamentally crippled because they need to dodge an encyclopedia of edge cases. The committee are really letting the vision of a good C++ down by refusing to break backwards compatibility to fix core problems. I'm talking fundamental types, implicit conversions, initialisation, preprocessor, undefined / ill-formed NDR behaviour. The C++ I'm passionate about is dead without some big changes I don't think the community can/will handle.
- bluGill 1y ago
  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 but I'm not sure how it fits (d supports c++ abi)
  - AnimalMuppet 1y ago
    60 million dollars a year in development for 15 years? What are you working on?
    - goalieca 1y ago
      There are many large projects with ~1000 engineers will end up costing more than that.
    - paulddraper 1y ago
      Chrome doesn’t fit those figures exactly but is close.
      - Yoric 1y ago
        ...and some components are being rewritten in Rust, if I recall.
        steveklabnik 1y ago
        Yep: https://news.ycombinator.com/item?id=45140641 https://news.ycombinator.com/item?id=45140641
        bluGill 1y ago
        Some small parts are. After several decades those small parts will add up but for now rust is almost nothing overall.
dwattttt 1y ago
> with the growing focus on safety, you can rest assured that an implementation that wouldn’t diagnose erroneous behaviour would be soon out of the game. Unless they were incumbent and inertia keeps them in. Or they're the only choice you have for a niche target. Or you have some other reason to keep them, such as (thinking?) the performance they bring is more important.
- jenadine 1y ago
  > The performance they bring is more important For this case, there is the [[indeterminate]] attribute.
webdevver 1y ago
C++26, C++29, C++32, ... C++50? Surely all good things come to an end, but where? i reckon there will be a C++29. what about C++38? C++43 sounds terrifying. Mid-century C++? there is no way in hell i will still be staying up to date with C++43. Personally I've already cut the cord at C++11.
- aw1621107 1y ago
  > Surely all good things come to an end, but where? As long as there are people willing to put in the work to convince the standards committee that the proposals they champion are worth adding to C++ (and as long as there is a committee to convince, I suppose), then new versions of C++ will continue to be released. > there is no way in hell i will still be staying up to date with C++43. Personally I've already cut the cord at C++11. Sure, different developers will find different features compelling and so will be comfortable living with different standards. That one group is fine with existing features shouldn't automatically prevent another from continuing to improve the language if they can gain consensus, though.
- jenadine 1y ago
  There is also COBOL 2023 and Fortran 2023. C++ will probably be quite niche in a few decades, but I don't see why it should stop being updated.
deleted 1y ago
[deleted]
0xCAP 1y ago
Why are we still trying to get C++ to become a viable choice instead of calling it a day and moving on? I guess it's my old theory that organisations turn into living beings and start living off of mere survival instinct even past the point of serving any purpose to society.
pwdisswordfishz 1y ago
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 given JavaScript syntax to be "improper": https://github.com/twbs/bootstrap/issues/3057#issuecomment-5136362 https://github.com/twbs/bootstrap/issues/3057#issuecomment-5...
- tialaramex 1y ago
  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 vendors already supply this but when it doesn't catch you arbitrary nonsense happens. #3 Zero init. Now not initializing has defined behaviour, all the diagnostic tools we saw in #2 are invalidated and must be removed, but did you actually mean zero? Awful bugs still occur and now our best tools to solve them are crippled. Ouch. #4 Erroneous Behaviour. Unlike #3 we do not invalidate those diagnostic tools from #2 because we've said the tool was correct. However, we do avoid Undefined Behaviour, something bad might happen but at least it's something you can reason about and it is clearly stated that it's your fault.
  - pwdisswordfishz 1y ago
    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.
- TuxSH 1y ago
  > 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)

52 points by todsacerdoti 1y ago

> It’s well-defined, yet incorrect behaviour that compilers are recommended to diagnose. Is recommended enough?! Well, with the growing focus on safety, you can rest assured that an implementation that wouldn’t diagnose erroneous behaviour would be soon out of the game. Is this to cover cases that would be hard/costly to detect? For example you pass the address of an uninitialized variable to a function in another source file that might read or just write to it, but the compiler can't know.

bluGill 1y ago
Right. The compiler needs to diagnose where it can but the are many cases it cannot be sure.

ratmeadow 1y ago

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? I've used C++ for so long and I'm a good way into thinking that the language is just over. It missed its mark because of backwards compatibility with fundamental language flaws. I think we can continue to add features - which are usually decent ideas given the context, kudos to the authors for the effort - but the language will decline faster than it can be fixed. Furthermore, the language seems to be continually becoming harder to implement, support, and write due to the constant feature addition and increase in semantic interconnectivity. To me it's almost mostly a theoretical exercise to add features at this point: practically we end up with oddly specced features which mostly work but are fundamentally crippled because they need to dodge an encyclopedia of edge cases. The committee are really letting the vision of a good C++ down by refusing to break backwards compatibility to fix core problems. I'm talking fundamental types, implicit conversions, initialisation, preprocessor, undefined / ill-formed NDR behaviour. The C++ I'm passionate about is dead without some big changes I don't think the community can/will handle.

bluGill 1y ago
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 but I'm not sure how it fits (d supports c++ abi)
- AnimalMuppet 1y ago
  60 million dollars a year in development for 15 years? What are you working on?
  - goalieca 1y ago
    There are many large projects with ~1000 engineers will end up costing more than that.
  - paulddraper 1y ago
    Chrome doesn’t fit those figures exactly but is close.
    - Yoric 1y ago
      ...and some components are being rewritten in Rust, if I recall.
      - steveklabnik 1y ago
        Yep: https://news.ycombinator.com/item?id=45140641 https://news.ycombinator.com/item?id=45140641
      - bluGill 1y ago
        Some small parts are. After several decades those small parts will add up but for now rust is almost nothing overall.

dwattttt 1y ago

> with the growing focus on safety, you can rest assured that an implementation that wouldn’t diagnose erroneous behaviour would be soon out of the game. Unless they were incumbent and inertia keeps them in. Or they're the only choice you have for a niche target. Or you have some other reason to keep them, such as (thinking?) the performance they bring is more important.

jenadine 1y ago
> The performance they bring is more important For this case, there is the [[indeterminate]] attribute.

webdevver 1y ago

C++26, C++29, C++32, ... C++50? Surely all good things come to an end, but where? i reckon there will be a C++29. what about C++38? C++43 sounds terrifying. Mid-century C++? there is no way in hell i will still be staying up to date with C++43. Personally I've already cut the cord at C++11.

aw1621107 1y ago
> Surely all good things come to an end, but where? As long as there are people willing to put in the work to convince the standards committee that the proposals they champion are worth adding to C++ (and as long as there is a committee to convince, I suppose), then new versions of C++ will continue to be released. > there is no way in hell i will still be staying up to date with C++43. Personally I've already cut the cord at C++11. Sure, different developers will find different features compelling and so will be comfortable living with different standards. That one group is fine with existing features shouldn't automatically prevent another from continuing to improve the language if they can gain consensus, though.
jenadine 1y ago
There is also COBOL 2023 and Fortran 2023. C++ will probably be quite niche in a few decades, but I don't see why it should stop being updated.

deleted 1y ago

[deleted]

0xCAP 1y ago

Why are we still trying to get C++ to become a viable choice instead of calling it a day and moving on? I guess it's my old theory that organisations turn into living beings and start living off of mere survival instinct even past the point of serving any purpose to society.

pwdisswordfishz 1y ago

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 given JavaScript syntax to be "improper": https://github.com/twbs/bootstrap/issues/3057#issuecomment-5136362 https://github.com/twbs/bootstrap/issues/3057#issuecomment-5...

tialaramex 1y ago
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 vendors already supply this but when it doesn't catch you arbitrary nonsense happens. #3 Zero init. Now not initializing has defined behaviour, all the diagnostic tools we saw in #2 are invalidated and must be removed, but did you actually mean zero? Awful bugs still occur and now our best tools to solve them are crippled. Ouch. #4 Erroneous Behaviour. Unlike #3 we do not invalidate those diagnostic tools from #2 because we've said the tool was correct. However, we do avoid Undefined Behaviour, something bad might happen but at least it's something you can reason about and it is clearly stated that it's your fault.
- pwdisswordfishz 1y ago
  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.
TuxSH 1y ago
> 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)