C/C++ is used over Ada just for familiar syntax. The coding standards used for safety-critical projects limit the features into a tiny safe subset, Essentially DSL. Linters and code checkers and static analyzers check the code more thoroughly than the compiler does.
For example, all memory is allocated during initialization. No allocation or reallocation from the heap afterward. That's why you see in the weapon specs familiar magic numbers like can track 256 targets simultaneously.
Commerical code analyzers used in the military, aviation, etc. are good but expensive. I have used https://www.absint.com/astree/index.htm
JOINT STRIKE FIGHTER AIR VEHICLE C++ CODING STANDARDS FOR THE SYSTEM DEVELOPMENT AND DEMONSTRATION PROGRAMDocument Number2RDU00001 Rev C December 2005 https://www.stroustrup.com/JSF-AV-rules.pdf
Yes. But as I said, programmers use just tiny subset of the language. Subsets are with additional checks are semantically very similar. Very dumped down code.
> being "just syntax" for a turing machine..
If you insist, I would describe them as intermediate representations for the back-ends for a non-Turing equivalent language (after all semantic checking).
Compilers parse text, check it matches the syntax, do some semantic checks, and then output native code (unless they transpile). When you write safety-critical code you can buy tools that make more far more checks to the semantics than the compiler and prevent the use of some constructs. Ada has SPARK that is integrated better.
For example, the tool I mention can prove that if code has no run-time errors or divisions by zero. It's essentially non-Turing equivalent language.
I would prefer Ada/Spark over C, but it don't matter that much, so I have always used C with tooling.
I don't know what they've done, but you could get a long way just by forbidding all dynamic allocation.
"Ada was seen as the technically superior and more robust language, but concern over the ability to successfully staff the software engineers required to develop the massive amounts of safety critical software caused the F-35 team to carefully look and finally to choose C and C++ for the implementation of safety critical software." - John H. Robb, Senior Manager of the F-35 Joint Strike Fighter Air Vehicle Software team at Lockheed Martin Aeronautics Fort Worth[1]
[1]https://web.archive.org/web/20111219004314/http://journal.th...
As soon as a coding standard for C/C++ doesn't completely forbid the use of pointers (which is completely impossible at least in C), then it will be much more unsafe than Ada (or other alternatives like Rust).
You can have - very painfully - near pointer free programming in C++, but it requires the use of high level constructs (smart pointers, RAII, etc) that most if not all safety critical standards forbid the use of.
Some people like the Frama-C people are trying to make programming in - a restricted an enhanced subset of - C, safe. They're basically doing Ada/SPARK with annotations in C, and it's horribly painful.
So, despite its informed and documented appearances, your comments are spreading misinformation about what it's like to program in C/C++ for safety critical systems.
C/C++ is used over Ada just for familiar syntax. From a safety perspective, the choice of language is inconsequential. With C/C++ the code analyzers used must do more work than with Ada but not that much.
All safety-critical code uses just a tiny subset of the language. It's like programming in a different language. Line-by-line coder reviews are a must.
That is completely and utterly false despite the millions (billions ?) invested in trying to make sound & safe static analysis tools for C/C++. I know you're trying to push that message but it couldn't be further from the truth. The nature of C & C++ is such that you cannot avoid unsafety, even with very restricted subsets.
Disclaimer: I work on Ada tools, but have also worked on C/C++ tools. I have also studied MISRA C and worked on such static analyzers for C & C++.
Citation very much needed. Some safety-critical projects choose to use Ada over C or C++, despite that there are far fewer Ada programmers out there, and that there are fewer development tools for Ada. The people running those projects presumably disagree with you.
We know that the choice of language is very consequential regarding cybersecurity. The many foot-guns of C and C++ are the root of a significant fraction of security vulnerabilities. Saying that these same foot-guns are of no consequence in safety-critical software seems like a remarkable claim.
This document [0] explicitly disagrees with your position that language is of little consequence. (Not to gloss over that it appears to have been funded by AdaCore, who are of course motivated to reach that conclusion.)
[0] See especially page 12: (PDF) https://www.adacore.com/uploads/techPapers/Controlling-Costs...
https://users.ece.cmu.edu/~koopman/pubs/koopman14_toyota_ua_...
• “Near-perfect” software
• Design out single points of failure
• Justify real time scheduling with analysis
• Watchdog timers that have real “bite”
• Good software architecture
• Good safety culture
This seems like mostly good concrete advice, although I think we can all agree that simply creating "near-perfect software" is a goal, not a solution. If you read up on Toyota's unintended breaking legal issues, it appears that it was most likely driver error, as Toyota did not issue a firmware change to the affected vehicles, and no software problems were ever identified.
* Niche golf game.
Knowing Lockheed-Martin, it's horrible mess of Java and JavaScript gathered from random geocities pages in 1990s.
well, it fits that the F-35 started as a horrible mess of JSF requirements bolted on top of Yak-141 from 1980s :)