Later, stupid compiler writers decided that since the wording allows anything to happen, it also allows time travel or memory corruption. These are not reasonable, but they are allowed by the wording of the standard.
The standard should be fixed to say it returns an undefined value or activates an error handling mechanism. Nobody could argue that time travel is an error handling mechanism.
The same is true for bit-shifts greater than type bit size and negative bit-shifts.
They are not bizarre but a good compromise between consistency and optimization for any possible existing and future CPU architecture.
What the author correctly points out to is that GSL implementation does not remove that undefined behaviour as it lacks the proper checks. And that is the problem as it does not fulfill its own documented guarantees.
tldr; C++ is just fine. The implementation in the library is wrong.
It's all up to the programmer who obviously won't invest the time because that would ruin the development velocity.
No it isn't. Using undefined behavior for things which can be implementation-defined behavior instead is harmful. It creates more space for bugs and security vulnerabilities.
I don't think IB has to be stable over time? For instance, whether and which extended integer types exist is IB and that has definitely changed over time.
> and that tools cannot report this behavior as a bug.
It's absolutely possible to report IB as a bug (or even fully-specified behavior, as demonstrated by -fsanitize=unsigned-integer-overflow or -fsanitize=implicit-integer-conversion).
To use C++ to code user programs is the actual mistake.
Think about assembly. Should assembly also be safe in all calls? That will make everything slower, and consume way more energy. Will you blame assembly if people used it to create a phone app and it had memory leaks? Or will you blame the developer for using assembly in the first place?
C++ is a tool designed for a range of purposes. There is a push to make it an universal language that makes everything well. But engineering is about making compromises.
For your use, C++ may be the wrong language. I do not disagree with you. But maybe you should be using another language instead. Or we should create a new language that fills the sweet spot that C++ covers, and then evolve C++ to be the safe language that you want. One way or another, it is a compromise.
Sorry for rambling so much, I hope I got my point across.
Yes. In 1985. Processor allow for things like garbage collectors that in the 80s would have been a terrible waste for most uses. Most game developers will never create a 3d engine while 80s developer will do their, 2d engines, by themselves.
Assembly was created to be able to create any kind of applications. In the 50s that made sense, not in the 80s.