DG OPINION ON SAFETY FOR ISO C++

Quote:
The NIST and NSA declaration could lead to several possible outcomes:

  non-government entities might ignore government directive AND/OR,
  government directive locks C++ out of certain market, and indirectly leads to a push away from
C++

Nobody knows which way this will go, and there could be other outcomes we have not anticipated. The
rest of this paper will champion that we stay calm and true to ourselves, and this is better than a
reactive jump on the bandwagon
---------

Obviously those leading the standards committee have been caught with their pants down on safety. They've "thought idly" about it but haven't bothered to really take it seriously, and now it's about to bite them in the ass in terms of government and international entities steering development away from C++, or actually locking it out even.

This has been an issue for C and C++ for decades, and a critical issue for more than 20 years (or more). Though the language is "safer" it is only as a side effect of efforts to simply reduce crashes and buffer overflows, and not to actually secure the language in general from abuse by bad actors via ensuring memory/type safety across the board as a goal in and of itself.

At this point it's unlikely that the group that steers C++ can do enough to secure the language at the level these government and international entities would consider acceptable particularly when working alternatives like Rust and others are available. But who knows what can be done if they put their minds/full effort behind taking this seriously. However given past history I doubt this can ever be a priority as it's simply not an area of work that C or C++ engineers seem to value. And if that's the case the inevitable locking out of C and C++ form an increasingly larger slice of the software stack is probably inevitable.

This comment isn't intended as any endorsement of Rust (which I don't use). Consider it an "I told you so" for C and C++ (which I do use).

Microsoft Research took that approach with "Checked C" and the current version is here:

https://github.com/microsoft/c...

I'm not sure if it comes close to offering the guarantees that Rust does, but I believe it's an attempt to provide a similar set of type and memory safety constructs while still essentially being a variant of C.

In any case, it's not about the syntax. I for one am not a fan of Rust's as a language. It's about the very reasonable goal of building software that has some form of baseline resistance to common vulnerability flaws built in.

There's more than one way to skin that cat. It doesn't have to be Rust but it should be something.

Here's a good current security vulnerability in Linux that has a score of 10 on the first page:

https://www.cvedetails.com/cve...

"The mq_notify function in the Linux kernel through 4.11.9 does not set the sock pointer to NULL upon entry into the retry logic. During a user-space close of a Netlink socket, it allows attackers to cause a denial of service (use-after-free) or possibly have unspecified other impact."

This is a classic "use-after-free" bug which is common in C/C++ but which can not occur in a secure language like Rust.

If you browse the historic Linux security vulnerability database, you'll find plenty of these types of vulnerabilities scattered everywhere.

It's not controversial that it's very difficult to write and maintain secure C/C++ code, and that the the cost of deploying insecure systems has dramatically multiplied in recent years with both criminal and state actors using vulnerabilities to create worldwide chaos.

If you don't see a problem here that's in serious need of fixing, you've been living under a rock.

So great, you do all of that but your expert C coder still accidentally introduces an off by one error in a complex algorithm that he just didn't catch. It passes peer review, and all of your tests.

So much for all of your training, security policy, proper requirements and testing. You did everything right, but your software is still insecure.

Yeah.. expert C programmers never write insecure code.

Except for when they do, which is pretty much constantly because true expert C programmers know it's impossible to write any large piece of C/C++ software using it's native features without making at least a few mistakes.

If you're a C programmer, and you don't already know this, then you aren't an expert.

He's not suggesting that at all.

"..I am seriously suggesting that when engineers refactor existing C code, especially parsers and other input handlers, they replace it — slowly, bit by bit — with Rust."

He's suggesting that when you refactor a critical piece of C code - in other words you're already going to change it and potentially add brand new C/C++ security issues - you instead use a language with some form of god damn formal verification and some fucking way of validating that you're not opening a new exploitable vulnerability that will bring down half the damn internet.

I mean is that really too much to ask?

I think you're missing the point.

The point is not that computer assisted programming environment will be easier for you to learn. The point is that it can make you dramatically more productive, allowing you to potentially write the same code that it might take a small team of programmers to write otherwise.

For example, having the system complete partial specifications or partial algorithms and intelligently (at least for a computer) fill in the blanks as you work means that you can work at a greater level of abstraction and be more productive. You will still need to dive into the details and directly code or specify the parts that the computer either doesn't complete correctly or doesn't yet understand (possibly because it was not part of it's training set or because it's entirely novel).

This is really not the sort of automation that makes it less complicated to write software, it's just deploying the advances in machine learning to automate boilerplate work and connect dots.

Efficiency and power are a good thing, and why shouldn't we use the power of the computer to automate this sort of stuff?

I wrote the original post on Lambda calling C++ a dead end, and I think what the article says about the standardization process is pretty accurate.

Essentially there are a set of issues real world C++ programmers must deal with when using the languages, particularly in large projects, that are never addressed by the standards committee. Enumerating a few by importance:

1. Stability, security, and memory safety.

Support for garbage collection, optional safe arrays, safe pointers, and bounds checking for sections of code. Code areas where reinterpret casts and other memory unsafe operations can be disabled and flagged as errors. Secure versions of the standard libraries. Etc.

Can anyone honestly say that security and stability in C++ code is not the singular most important issue for C++ presently? How many times have security, stability, or memory safety been even mentioned in the C++ 0x standardization process? I've browsed through many of the papers and have yet to see it mentioned a single time (possibly there are one or two mentions in the GC papers).

2. Ability to integrate with other languages, particularly managed and dynamic languages.

Reflection support, decidably parsable declarations, support or standardization of in/out semantics on declarations, etc. I would say for many (if not most projects) dealing with the "C++ as an insular world unto itself" is one of the next most glaringly problematic aspect of the language. Few languages go to greater lengths to make integrating with the outside world more difficult.

3. Issues with separate compilation, headers and macros.

BS made a half hearted attempt to mitigate the issues arising from the use of the include file model, and macros in C++, but it was quickly abandon. The problems (particularly in large projects) with the separate compilation model, (increasing time involved in parsing large headers), problems with macro leakage, and other issues in the essentially broken C style compilation model are a major source of continuous pain for C++ programmers.

There is no reason why the language can not continue to be backwards compatible with separate compilation and macros, but can be moved forward towards a more workable model for new code.

4. The inability to ever "deprecate" features.

The language can be progressively improved, but only by some sort of an official program of scheduling certain features for deprecation. Insecure C functions and libraries, unused standards, etc. This kruft unneccessarily complicates the introduction of new useful features, and makes it difficult to maintain production code (which typically become new code combined with a random collection outdated programming practices and library includes which must constantly be "code reviewed" out).

5. The inability to add features from other languages that do actually work.

What is important and "works" for one programmer is a superfluous and useless add-on for another. But there are features of java, C#, and dynamic languages that C++ would do well to imitate. These features are rarely even discussed in favor of serving the template meta-programming community and those who feel the language should add a host of other esoteric features to the corner case use scenarios of the language.

I've been writing C++ for more than 20 years, and I've dealt first hand working with a huge C++ project when working with ILM's large code base that exposed more than a few of the gaping weakness of this language. I was looking forward to.. at least.. some help in dealing with the impossibility of maintaining large amounts of template code, of which that code base had multiple nested layers. An error in one template parameter class cascades downwards into an infinite incomprehensible mess of template substitution errors. But the committee says "No concepts for you!"

Well, C++ does import C and C++ header files, but I don't think it addresses any other of these issues. Can I: o Change the binary representation of a string literal to something other than string-z? o Create a Container class which is implemented as a list, an array, or merely a sequence of statements depending on how it's actually used? o Control the way exceptions, inheritance, object construction/deletion, or memory management is implemented. o Completely ignore the differences between functionally identical data types with different implementations? o Write a memory management library that would automatically generate the propert "delete" statements for every "new" in a single threaded application. o Write "printf" like function which would check the syntax of its own format parameters at compile time. I don't think C++ can do any of this at the present. I really want a language which will allow me as a library designer to use the best implementation strategy for what the user is trying to do. That requires that I be able to analyze the user's code and even its runtime characteristics, and generate the most efficient implementation of any class with the least overhead. This requires that classes and methods be abstractions, not actual concrete representations as in C++/C#/or Java, that can be replaced by a variety of different concrete implementations at compile time.