Sorry. I work in automotive embedded systems(although not personally in safety-critical parts we use the same parts and rules) and I can tell you rules like yours were behind this.
We are following all these rules and so we are safe. We can save a penny per 1000 units sold using a crappy MMU-less CPU.
First of all, following the stupid rules requires you to use baroque lint imitations which will go off on every line of idiomatic C. You need a paper trail to justify every line of code. Seems about right, people's lives are in danger, right?
Now consider that the controller system is hundreds of thousand of LOCs(for us it's more like millions). Most of that is crap boilerplate code required by the standards. This means if you follow that methodology strictly, you need hundreds of people going through mindnumbing lists of "You are not using this argument/This code assigning an argument to itself does nothing". Given that most software developers are inept and overworked, I can give you a certificate that there will be bugs.
It took me two weeks with the code to find a checksum function used all over the place that had been "fixed" to detect offset data after some earlier corruption bug was not detected.
Every 256 bytes "checksummed", a bit from the input would be left unaccounted(And it was actually used for data several times larger than that). I know for a fact that had to go through at least three source and design reviews and at least one more design review with some fat managers higher up.
Now tell me you feel safe.
Note to PHBs: Googleing up a fucking working CRC and getting a CS PhD to make a formal proof that it will work as intended would have cost far less.
Also, you see, the crappy CPU vendor stack measuring tools - that rules say we must use to guarantee safety - don't account for function pointers(they do show scary icons for recursive functions). They say foo(384) bar(uhhm... maybe 0?) I know to look for that when I add calls to function pointers, but I guess most people don't.
Now you add another rule. LOZRA 4092: You can't use function pointers at all.
Make my life more miserable, give the remaining work I will be unable to do to Dave, the monstera plant, or someone with the same programming aptitude.
I will give the crappy CPU/Compiler/RTOS vendors that should be sued free advice:
0- Add an MPU
1- Add canaries to every function call with any local variable at all(here it's not hackers it's programmers following LOZRA 396: cast the shit off everything so the compiler can't tell)
2- Add stack overflow canaries on every task switch. (add an MPU and align to page in the stack growing direction)
3- Add canaries to any memory pool allocation. (add MPU dead pages - You don't need RAM, just fucking address space of which you are using like 2%)
4- If any of the above traps, jump to a customer defined function(stored in ROM than can only be physically modified by outside hardware) that puts all vital hardware in a safe state, adds a record to the black box and reset the whole thing from scratch.
5- Forget about tasks and threads and move on to processes running on separate address spaces. If information must flow from a to b it better go through accepted channels.
6- Did I tell you to add a fucking MPU!?