4 ms·

There is. It's called "undefined opcode".

tialaramex 4y ago
Undefined Opcodes are just like C++ UB. They're very bad news, but they're nothing compared to how terrible IFNDR is. I think C++ programmers either don't realise how bad IFNDR is, or they just don't want to think about it. IFNDR means your entire program is always meaningless. Let's take a UB example, an IFNDR example, and an undefined Opcode example and compare the potential consequences 1. UB example. We have a program which does some work in a loop, the user can select how many times between 0 and 256 the loop should execute. Unfortunately this should have been limited to 255 times, if the user picks 256 the loop exit condition is always false. In C++ this is Undefined Behaviour and the program's behaviour is arbitrary once that arises. So long as you never select 256 in the loop iteration setting, this program is fine. 2. IFNDR example. This program only lets the user select between 0 to 200 iterations. Unfortunately if more than 10 iterations are used the arithetic inside the loop uses a std::vector of floating point values with an algorithm specifying that the values are std::totally_ordered, as a result this is IFNDR because floating point values are a structural match, so this compiles, but they aren't a semantic match for the total order concept and that's IFNDR. Even if the feature is never activated and nothing is ever processed with the std::totally_ordered algorithm, the behaviour of the entire program is undefined, the program has no meaning at all. Running this program at all could cause anything to happen. 3. Undefined Opcode. This time the program has between 1 and 100 iterations, it's written in assembly but unfortunately due to an oversight for the odd numbers of iterations the undefined Opcode GLARK R0,R0 is executed which only works on a model of CPU which you don't have. This program misbehaves, perhaps spontaneously rebooting or showing other bizarre behaviour - but only if that Opcode is executed, which for even numbers of iterations never happens. So long as you only use even numbers of iterations, this program is fine.
- gpderetta 4y ago
  1) data races are undefined at the hardware level 2) poking at random memory mapped hardware registers can produce such forms of UB that C++ can only dream to.
  - tialaramex 4y ago
    > data races are undefined at the hardware level Um, what? To have a data race you need a formal model that doesn't exist for the hardware. > poking at random memory mapped hardware registers can produce such forms of UB that C++ can only dream to. When they say "Undefined" they really meant it, C++ UB is allowed to do MMIO, or whatever else.
    - gpderetta 4y ago
      > Um, what? To have a data race you need a formal model that doesn't exist for the hardware. Intel and other manufacturers do provide a model for their hardware (although it is a relatively recent thing and has been formalized outside of intel). > When they say "Undefined" they really meant it, C++ UB is allowed to do MMIO, or whatever else. Well, I do give you that.
- AnimalMuppet 4y ago
  If you have examples of #2 happening, in production code, from production compilers, then we might start to care. Examples, plural. Not just a handful, either. Enough examples that it becomes a statistically valid actual concern for those of us writing C++. Otherwise... yeah, theoretically there could be monsters hiding under your bed. To be really safe, you should throw out your bed and sleep on the floor. But you're not going to, because the threat is theoretical but not real.
  - tialaramex 4y ago
    What would an "example" of these facts about how C++ is defined even mean? As you've observed, you don't care anyway, you can clamp your hands firmly over your eyes and see no evidence of a problem. The Committee doesn't need to write more, and more, and more IFNDR into the language standard - there are other ways forward, but it's easier and C++ programmers have had their hands clamped hard over their eyes for decades at this point so why not ?

Undefined Opcodes are just like C++ UB. They're very bad news, but they're nothing compared to how terrible IFNDR is. I think C++ programmers either don't realise how bad IFNDR is, or they just don't want to think about it. IFNDR means your entire program is always meaningless. Let's take a UB example, an IFNDR example, and an undefined Opcode example and compare the potential consequences 1. UB example. We have a program which does some work in a loop, the user can select how many times between 0 and 256 the loop should execute. Unfortunately this should have been limited to 255 times, if the user picks 256 the loop exit condition is always false. In C++ this is Undefined Behaviour and the program's behaviour is arbitrary once that arises. So long as you never select 256 in the loop iteration setting, this program is fine. 2. IFNDR example. This program only lets the user select between 0 to 200 iterations. Unfortunately if more than 10 iterations are used the arithetic inside the loop uses a std::vector of floating point values with an algorithm specifying that the values are std::totally_ordered, as a result this is IFNDR because floating point values are a structural match, so this compiles, but they aren't a semantic match for the total order concept and that's IFNDR. Even if the feature is never activated and nothing is ever processed with the std::totally_ordered algorithm, the behaviour of the entire program is undefined, the program has no meaning at all. Running this program at all could cause anything to happen. 3. Undefined Opcode. This time the program has between 1 and 100 iterations, it's written in assembly but unfortunately due to an oversight for the odd numbers of iterations the undefined Opcode GLARK R0,R0 is executed which only works on a model of CPU which you don't have. This program misbehaves, perhaps spontaneously rebooting or showing other bizarre behaviour - but only if that Opcode is executed, which for even numbers of iterations never happens. So long as you only use even numbers of iterations, this program is fine.

gpderetta 4y ago
1) data races are undefined at the hardware level 2) poking at random memory mapped hardware registers can produce such forms of UB that C++ can only dream to.
- tialaramex 4y ago
  > data races are undefined at the hardware level Um, what? To have a data race you need a formal model that doesn't exist for the hardware. > poking at random memory mapped hardware registers can produce such forms of UB that C++ can only dream to. When they say "Undefined" they really meant it, C++ UB is allowed to do MMIO, or whatever else.
  - gpderetta 4y ago
    > Um, what? To have a data race you need a formal model that doesn't exist for the hardware. Intel and other manufacturers do provide a model for their hardware (although it is a relatively recent thing and has been formalized outside of intel). > When they say "Undefined" they really meant it, C++ UB is allowed to do MMIO, or whatever else. Well, I do give you that.
AnimalMuppet 4y ago
If you have examples of #2 happening, in production code, from production compilers, then we might start to care. Examples, plural. Not just a handful, either. Enough examples that it becomes a statistically valid actual concern for those of us writing C++. Otherwise... yeah, theoretically there could be monsters hiding under your bed. To be really safe, you should throw out your bed and sleep on the floor. But you're not going to, because the threat is theoretical but not real.
- tialaramex 4y ago
  What would an "example" of these facts about how C++ is defined even mean? As you've observed, you don't care anyway, you can clamp your hands firmly over your eyes and see no evidence of a problem. The Committee doesn't need to write more, and more, and more IFNDR into the language standard - there are other ways forward, but it's easier and C++ programmers have had their hands clamped hard over their eyes for decades at this point so why not ?