The C programming language has undoubtably extremely successful. It consistently ranks highly in the various rankings of most popular programming languages however these studies seem to be measured. C is not a language that is naturally suited to having safety requirements given to it. So, unsuited is it to safety that the basic safety publication does not recommend C for any integrity level.

Using C safely is not a task for the timorous or the brash software engineer. It took fully a quarter of a century before guidelines were first published by MISRA with "assistance to the automotive industry in the creation and application within a vehicle system of safe, reliable software."

At that time the language, the hardware and the compilers were essentially all new. People not unlike yourself were using and learning through using and more than likely learning from recovering from complex mistakes. Fully one third of the MISRA C rules are guidance relevant only if the compiler does something the developer does not understand or expect. In fact, the frustration people new to MISRA C find is because the behavior of their compiler is in fact a mystery to them, and they have experience of at most two compilers.

By and large the remainder of the rules are roughly language independent maintenance issues. Underlying insecurities are shared with other quite different programming languages and mistakes are regularly made and made again by developers. These mistakes seem agnostic to the backgrounds, training, geographical location of the developers making them. Something about programming means developers make the same mistakes repeatedly, generation after generation, location after location.

MISRA was rightly concerned about the long-term effects of mistakes in an increasingly complex code base. Never did anyone expect the complexity of the software on the vehicle back in those days.

Compiler vendors came and went. The good ones survived. Code checkers came and went, the good ones survived. Developers came and went and the good ones left or retired and here we are nearly another quarter of a century later and a quick look at any open sourced C repository confirms that developers are still making the same mistakes that if present on an automobile result in at least extremely expensive repairs being needed, jail, and or, deaths.

A recall by NHTSA is safety related. Looking over the trends over the last decade in most all areas the recall trend is not just increasing but increasing more rapidly year on year. Of course, this is not all the responsibility of the C language and I'm sure things would have been much worse without the efforts of the MISRA committee.

This blog is certainly not a criticism in any way of the magnificent work performed around the world driving up software quality, expecting failure modes and creating innovative safety mechanisms that we routinely rely on without even being aware of them.

Nevertheless, there is a new challenge arising that is likely even more damaging than under trained, under experienced, under pressure embedded safety related C developers have yet experienced.

The problem is the world does not have enough developers and a programming language ideally suited to safety has been conceived, designed, implemented, and increasingly getting used for safety related applications.

More than likely your compiler vendor has already shifted the goals of their top talent away from C and towards Rust.

This means we have reached peak C. A peak in that right now arguably we have the safest, most compatible, most well-developed compilers, tools, code, and supporting education material ever. This is based on nearly 50 years of experience with the language. As resources are diverted away from C to rapidly adopt Rust and provide the toolchains suited to the hardware automotive prefers C will no longer be getting the time and attention it has received help from so far. Fewer people will be using C, more code will start life as Rust and be backported, if necessary, fewer bugs will be filed, fewer bugs will get fixed. In reliability language C for safety has reached its useful life. The excellent work performed by the MISRA committee when the language was still in its infancy and the relatively uneventful use is coming to an end. Sure, there have been very high-profile mistakes with C costing billions of dollars but overall, it is surprisingly low given the enormous quantity of code that must be supported. Compared to say medical devices.

In the next decade we need to expect more attempts to quickly convert C into Rust. Increasingly more frustrated developers now wrestling with a seemingly unnecessarily pedantic compiler and for the first time a run-time.

The decade after that it will become increasingly difficult to find a supported compiler beyond those already available in the open. More than likely to better support the tail end of developers with dwindling support revenue traditionally closed source compiler vendors will make more open releases of their code as an experiment to see if community support can keep their product going when they can't. There will of course remain gcc and its variants. Hard to see that going away since Rust is not the right solution is so many other realms using C.

For automotive , this is a good thing though. C was not developed with safety in mind. Speed of execution and speed of compilation, on the machines at that time, was more important. Rust seems able to reconcile both the speed of execution with the needs of safety. Regarding safety a recent analysis I performed with the help of my good colleagues at Codethink Ltd. confirmed that approximately 90% of the mistakes anticipated by MISRA C (and a few other insecurities exida has gathered of the years) are either not possible, prevented at compile time or detected at run-time by Rust. This is a fabulous achievement for the language and inevitably will lead to frustration as developers get to grips with object lifetimes and the borrow checker. In fact, replacing portions of projects written in C with Rust is considered best practice and, in many cases, highlights hidden and obscure bugs in the C being replaced.

A qualified tool chain is also a top priority for the Rust development committee. Something that didn't appear for C for 30 years after the language was invented.

A qualified tool chain doesn't stop you making mistakes using the compiler but is certainly extremely valuable and might indicate more maturity than say the early embedded automotive C compilers that couldn't for example discriminate more than 8 characters of an identifier or silently processed a dangling else. I know you have checked your compiler doesn't do that. The language itself wasn’t standardized until 1983.

There are two things that become important for our planning and anticipation of the future state of embedded software.

Firstly, just like the experiences of those in the late 80s dealing with an immature programming language, immature compiles and no supporting tools, and developers new to C we need to anticipate our compilers and tools waning in their capabilities despite I’m sure the potentially loud marketing claims from the vendors that these predictions are not valid in their case.

Secondly, the result of this, as I said back in 2022 at our annual Symposium, is that we can't ignore Rust. All safety publications recommend the use of a suitable programming language. C is not suitable without very pedantic supporting activities. Rust seems to be suitable. It would be dereliction of duty, maybe even negligent, not to start seriously considering a transition away from C where the integrity has already peaked.

If the issues raised here are of interest to you, please do get in contact with me.

Selected references:

https://misra.org.uk/a-brief-history-of-misra/
https://www.bell-labs.com/usr/dmr/www/chist.html
https://blog.ansi.org/2017/09/origin-ansi-c-iso-c/
https://www.exida.com/blog/software-metrics-iso-26262-iec-61508
https://www.stout.com/en/insights/report/2021-automotive-warranty-and-defect-report
https://ferrous-systems.com/blog/officially-qualified-ferrocene/
https://www.exida-eu.com/images/home/exida_Automotive_Symposium_2022_V3.pdf