C++ creator Bjarne Stroustrup defends its safety

US National Security Agency recommends using memory safe programming languages instead of C/C++ when possible, because hackers frequently exploit memory issues.

A magnifying lens exposes an exploit amid binary code.
Creativan

The creator of C++, Bjarne Stroustrup, is defending the venerable programming language after the US National Security Agency (NSA) recently recommended against using it. NSA advises organizations to use memory safe languages instead.

Responding to the agency’s November 2022 bulletin on software memory safety, Stroustrup, who designed C++ in 1979, stressed decades-long efforts to enable better, safer, and more efficient C++. “In particular, the work on the C++ Core Guidelines specifically aims at delivering statically guaranteed type-safe and resource-safe C++ for people who need that without disrupting code bases that can manage without such strong guarantees or introducing additional tool chains,” Stroustrup said in a published response.

The NSA bulletin recommends against the use of C/C++ because, despite programmers often performing rigorous testing to ensure code is safe, memory issues in software still comprise a large portion of exploited vulnerabilities. “NSA advises organizations to consider making a strategic shift from programming languages that provide little or no inherent memory protection, such as C/C++, to a memory-safe language when possible,” the agency said.

The agency cited memory-safe languages such as C#, Go, Java, Ruby, Rust, and Swift.” NSA said commonly used languages such as C and C++ provide freedom and flexibility in memory management while heavily relying on the programmer to perform checks on memory references.

But Stroustrup emphasized improvements to safety. “Now, if I considered any of those ‘safe’ languages superior to C++ for the range of uses I care about, I wouldn’t consider the fading out of C/C++ as a bad thing, but that’s not the case. Also, as described, ‘safe’ is limited to memory safety, leaving out on the order of a dozen other ways that a language could (and will) be used to violate some form of safety and security.”

He also lamented NSA’s memo pairing C++ with the older C language. C++, originally called C with Classes, is an extension of C. “As is far too common, it lumps C and C++ into the single category C/C++, ignoring 30-plus years of progress.” In an email to InfoWorld late last week, Stroustrup added, “Yes, far too many people talk about the mythical C/C++ language and then often proceed to focus on the weaknesses of the C part. Many of those weaknesses can be avoided in C++; typically, by writing more-efficient code that more directly expresses the intent of the programmer.”

Stroustrup in the email also shared his definition of safety: He aims for type and resource safety, in which every object is used according to its type and no resource is leaked. For C++, this implies some runtime range checking, eliminating access through dangling pointers, and avoiding misuses of casts and unions. C++ offers high-level facilities, such as containers, span, range-for loops, and variants that can offer guarantees without damaging productivity or efficiency. Regarding the so-called safe languages the NSA cited, Stroustrup said all of the languages are vulnerable through code that is not statically verified. Further, every system must use hardware, and effective hardware access is rarely safe, he said.

Stroustrup outlined his strategy for safe use of C++:

  • Static analysis to verify that no unsafe code is executed.
  • Coding rules to simplify the code to make industrial-scale static analysis feasible.
  • Libraries to make such simplified code reasonably easy to write and ensure runtime checks where needed.

Stroustrup said there are millions of C++ programmers and billions of lines of C++ code. Primary current uses for the language include aerospace, medical instrumentation, AI/ML, graphics, bio-medicine, high-energy physics, and others.

NSA acknowledged that memory management is not entirely safe even in a “memory-safe” language and that mechanisms such as static and dynamic application security testing (SAST and DAST) can be used to improve memory safety in so-called non-memory-safe languages. But neither SAST nor DAST can make non-memory-safe code totally safe, NSA said.

Copyright © 2023 IDG Communications, Inc.

How to choose a low-code development platform