Time to make C the COBOL of this century

Lions juggling chainsaws are fun to watch, but you wouldn't want them trimming your trees

Opinion Nobody likes The Man. When a traffic cop tells you to straighten up and slow down or else, profound thanks are rarely the first words on your lips. Then you drive past a car embedded in a tree, surrounded by blue lights and cutting equipment. Perhaps Officer Dibble had a point.

There's no perhaps about the FBI and CISA getting snippy at buffer overflows. These people worry about exploits that threaten car-crash incidents in enterprise IT, and they've seen enough to get angry. It's not that making mistakes is a crime when writing code. No human endeavor worth doing is without error. It's more that this class of bug is avoidable, and has been for decades, yet it pours out of big tech like woodworm from a church pew. Enough already, they say. They are right.

You know all about buffer overflows. A coder moves data from A to B, but doesn't check that A will always fit in B. When it won't, it gets copied into the memory beyond B, which may be catastrophic. Let's call that memory C for catastrophe. Or chaos. Or, well, C.

Among the many remedies suggested by the Feds is ditching C and its chaotic family in favor of more modern languages that have robust defenses against creating buffer overflows. Which C most definitely does not. It is a chainsaw of a language without safety guards, born in the time when if a programmer wanted to cut their own femoral artery open, then they're the boss. Some circus performers can juggle with chainsaws. You do not want chainsaw-juggling gift-sets sold for family Christmas presents.

You don't have to abandon C to be safer, as the Feds point out. You can do better testing, in lots of ways. You can use safe coding practices and inspection tools. We have computers that can compile the entire Linux source in minutes. There is no excuse not to use such raw power to do a heck of a lot more work in testing code as well.

This is at the core of the bug watchers' frustration. The same companies that are burning billions on AI that nobody asked for aren't bothering to spend a fraction of that in clearing up their messes.

Everyone else who sells services and goods to others has responsibilities and consequences. An electrician who wired 240-volt circuits to 115-volt outlets would not last long. Nor would a plumber who used one-inch pipes for toilet outlets, if you want a real buffer overflow. Yet companies like Microsoft do this to millions of customers when they don't have to, and they're free to keep on doing it.

Yes, testing is expensive and doesn't guarantee safety. Guess what? Testing becomes quicker, easier, and cheaper if you're testing code that doesn't have so many errors in it. No need to check for a class of mistake when that class has been eliminated earlier in the pipeline. Which brings us back to the choice of coding platform and especially the choice of language.

Changing language is hard, and it gets harder the better you are at what's being changed. The world's best chainsaw juggler is not going to want to move to precision safety cutters. If your business is built on an ecosystem of chainsaw-juggling kits, and the blood spilled ain't yours, then why is it anyone else's business? The challenges to an organization aren't just technical; they're cultural and personal and should not be underestimated. Look at the Rust rumblings in the Linux kernel, where ringmaster Linus is having to use his lion-tamer whip on some big beasts.

None of this is an excuse for not making the move. There will come a time when C becomes the COBOL of the 21st century, and the faster that happens, the less blood will stain the pavements of the information superhighway. Doing things badly when you know how to do them well leads to irrelevance, even extinction, sooner or later. Writing and shipping better code is a competitive advantage once you have the processes to do it efficiently and the people to do it well.

Transition costs are one-off, ongoing savings are forever. How soon do you want to get there? What are you doing to make it happen?

It's also great to be on the side of the angels when sins become crimes. If bad practice is called out enough times and is still deliberately ignored, the door opens to making it actionable. A new law or even just a court case on what we have on the books now could do it – an exploit caused by avoidable bad code makes a company explicitly liable. Defining legally bad code is hard, but making the use of known good methods an acceptable defense is in line with logic.

That list won't include "Don't use C," at least not immediately. One day, it may be needed, if the problem persists long enough. It's far better not to make that happen by making C history, at least in production code that can cut not just your leg off but those of millions of users. Those chainsaws can't rust up quickly enough. ®