That pdf reads like the first draft of a guide on "how to write safety-critical code" and probably inspired things like DO-178, LOR1, DAL-A, 882, all sorts of standards.
Writing C code for a safety-critical system running on an RTOS really humbled me. Felt like I should make more than I did relative to peers slinging code using 748mb of ram in a browser tab. ;D
For me too. TFA is, I think, the first coding standard I came across that made sense to me. Except for the "2+ assertions per function" rule. 2 is arbitrary for one thing, and secondly your top priority, in the context of mildly mission critical embedded code, is to do what it takes to keep your system alive and sane (as fault tolerance people put it). Then log the issue if you can. Downtime caused by a program abort followed by a watchdog reboot should be a last resort for things that you really couldn't possibly expect and therefore cannot handle properly - there's no such thing as an "unexpected error".
Also before that, design things so that errors cannot happen; for instance use C's type system, as weak and clunky as it is, to make it is hardly possible to pass out-of-range parameters. There's a trend these days to bash-at-will C for its "unsafe" nature, but a significant part of the issues are "between the keyboard and the chair", that is not doing the right thing because it is tedious - that's probably the main defect of C.
“2+ assertions” could be read as “a precondition, a postcondition, and maybe a loop invariant”. The guideline should perhaps be more explicit about asserting your pre- and postcondition, but that’s a perfectly natural minimum standard.
As for C’s unsafety — it is a poor engineer who doesn’t account for human factors. A language that doesn’t mitigate PEBKACs, and which lacks affordances to make safe code less tedious, is intrinsically unsafe.
Airbus writes all their flight control software in C, but it's not C as you would find in say your Linux distro, more like a tightly controlled subset of C with its own compilers, toolchains and formal verification. So they're already writing it in a different language, just one that superficially looks like C.
Totally makes sense to choose Ada (definitely not a new language!) for green field development. But as I understand it, the Airbus flight control systems are millions and millions of lines of "C", and they ain't getting rewritten any time soon or probably ever. However they do invest a lot in toolchains and formal software verification (in Newport, Wales).
Right. If you want a safer language than C for your safety-critical embedded code, the obvious choice is Ada. The article even mentions Ada specifically.
No doubt you could implement a modern web API in Ada, but you wouldn't really be playing to Ada's strengths. Ada is more commonly associated with safety-critical embedded work than with web development.
Ada Web Server (AWS) [0][1] is Free and Open Source software, but that framework doesn't seem to get much use, and it doesn't inspire confidence that [0] mentions SOAP but doesn't mention JSON. I'm not aware of any proprietary/payware Ada web server solutions.
Yes, rewriting all the world's software in boutique untested languages is surely the way to write safe and reliable software.
Because, you know, all the crusty idiots writing software before you didn't know about the wonders of syntactic sugar and automatically installed dependencies.
Writing C code for a safety-critical system running on an RTOS really humbled me. Felt like I should make more than I did relative to peers slinging code using 748mb of ram in a browser tab. ;D