Bob Pease was a staff scientist at National Semiconductor and wrote for Electronic Design for decades. His typical article was entitled “What’s All This Stuff, Anyhow?”, with “Stuff” being interchanged with the topic at hand. I figured this editorial might be a good way to honor him while touching on a topic I find very important especially in this age of vibe coding (take the vibe coding poll) and AI hysteria.

In any case, the focus this week is on creating safe and reliable software. The tools to make it happen are well-established. AI is being employed to streamline the development process and even generate code. Still, compilers, static-analysis tools, and certification processes remain, as it should even for applications that aren’t destined for a car, medical device, or aircraft.

The interesting aspect is that creating highly reliable software is also the way to create software that doesn’t have bugs. It should be the goal for any developer, especially these days when AI is used to craft attacks based on bugs in applications.

In Search of the Safe Software Magic Bullet

Too many programmers think they can write software without bugs and choose C because it generates more efficient code. It’s true that it’s possible to write code without bugs in any language and C can generate efficient code. It’s not true that most developers will be able to do this on a regular basis. In fact, it’s rare that anyone can write bug-free code of any substantial size without resorting to additional tools. It only takes one bug to provide a potential attack vector or cause a program to fail accidentally.

I think Ada/SPARK’s contracts are the best thing for developing dependable software; programming languages like C/C++ have a significantly larger user base. Likewise, Rust’s memory-management capabilities are great, but it has yet to make a major dent in the C/C++ code base. That’s changing, though — it’s now a language that can be used to do some internal Linux development, which has been dominated by C.

There seems to be increasing interest in standards like MISRA C and MISRA C++. However, these tend to be band-aids rather than focused bug mitigation tools like contracts and built-in memory manipulation support.

Functional safety is hard because these tools are needed, but it’s just the first level of checking that needs to be done. This is why the process for certification of software is more complex. It’s not typically needed for most applications, even embedded ones. Still, the more that’s done along these lines, the better.

The big problem with static-analysis tools when it comes to C and C++ is that the best tools are commercial, closed-source products. That’s not to say the situation is bad, as the cost of using these tools make them invaluable in keeping planes in the air and ensuring self-driving cars won’t run you over, usually. The problem for me is that the average C/C++programmer doesn’t have access to them.

Cppcheck and Clang Static Analyzer (CSA) are the best open-source alternatives at this point. CSA is built on Clang and LLVM, which is great if you’re already using a compiler based on them. There’s a commercial version of Cppcheck, Cppcheck Premium, so that tends to be an exception to the comment above. It’s the only one I’ve found thus far, though.

I highly recommend using one of these or a commercial tool if you’re doing any kind of C/C++ development. They won’t catch all your bugs, but they will make a significant dent. Every bug caught by these tools is one less to worry about and gives more time to find those that aren’t found automatically.

Can AI Help Develop Better Software?

Artificial intelligence and machine learning (AI/ML) have been used to create software as well as track down bugs. The press tends to highlight its hacking abilities, including the ability to find lots of bugs, much to the chagrin of the developers. I wonder if the vibe coding of large language models (LLMs) causes embarrassment if their vibe code has bugs?

In any case, AI will augment other bug tools and will be employed to develop suggested fixes whether we like it or not. The challenge for developers, or their AI coding assistants, is to determine whether the fixes are good or if they inject new bugs that may be worse. This AI augmentation may not be as repeatable as the other tools like static analysis, and false positives can be an issue. However, in the long run, they’re likely to be a regular adjunct to other tools used to minimize errors in applications.

I would like to do a survey on this topic, but that will have to wait. For now, if you have comments and can find the comment system below, please add one there so that everyone can provide feedback.

In the meantime, I’m going to see about adding the Cppcheclipse plugin in Eclipse, my default IDE.

More Electronic Design Weekly