{"id":58172,"date":"2025-02-18T14:01:05","date_gmt":"2025-02-18T14:01:05","guid":{"rendered":"https:\/\/www.threatshub.org\/blog\/time-to-make-c-the-cobol-of-this-century\/"},"modified":"2025-02-18T14:01:05","modified_gmt":"2025-02-18T14:01:05","slug":"time-to-make-c-the-cobol-of-this-century","status":"publish","type":"post","link":"https:\/\/www.threatshub.org\/blog\/time-to-make-c-the-cobol-of-this-century\/","title":{"rendered":"Time to make C the COBOL of this century"},"content":{"rendered":"

Opinion<\/span> 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.<\/p>\n

There’s no perhaps about the FBI and CISA getting snippy at buffer overflows<\/a>. 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.<\/p>\n

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.<\/p>\n