> One point of note is that O'Callahan's "Vapourware" post points out a problem that's solvable, it isn't some big blocker the way he claims it is.

No, it is a big blocker. In fact, it's the same as the problem I pointed out, just with global variables instead of shared ptr. Aliasable mutable data is the fundamental unsolvable problem; whether it arises through global variables or shared ptr is just a detail.

> The rest of your post shifts the question from "is there a culture of secure, maintainable, and understandable software" to "Is C++ software free of memory flaws." Are these concepts not distinct to you?

Software that has memory flaws that enable remote code execution is not secure.

> No, it is a big blocker. In fact, it's the same as the problem I pointed out, just with global variables instead of shared ptr.

Imagine refactoring a program to not use globals but instead pass them up by const or mutable reference to where they're used. The checker can do the same imagining with an effect system.

> Software that has memory flaws that enable remote code execution is not secure.

Words have meaning.

> Imagine refactoring a program to not use globals but instead pass them up by const or mutable reference to where they're used. The checker can do the same imagining with an effect system.

Not at all. This requires higher order control flow analysis, which is pretty much guaranteed to fall down in all sorts of cases.

But you don't need the system to be precise or accept every correct program. Heck, you'd get pretty far with a simple conservative yes/no on whether a function might touch any globals. At least at that point you could copy-construct from a global. You could skip adding any complex mechanisms and just say, hey, every function instantiation/global variable combination is going to get a plain mutates/reads/no, which translates to how things would be if the mutable/const references was passed up from main, and if that ain't flexible enough for you, have your closure/object capture a reference to the global and we'll track it that way. [1] Of course that could get replaced with a specific annotation mechanism where we don't really put a reference in the object. But regardless, what this does is handle the problem of global variables for the set of global-using programs which you could still write, without having to think too much, if there were no global variables in the language at all.

[1] Edit: A mechanism for annotating that a class or method does not get implicitly passed globals would be very useful for things like std::function<>::operator() so that std::function objects are forced to access globals by capturing them, because totally unrelated uses of a std::function could stomp over the same type instantiation for this ultra-dumb analysis.

Edit: Here's the tl;dr version. One solution to the global variables problem is for the CppCoreGuidelines to say, "Don't use globals." Another is for them to say, "Don't use globals, but for the 90%-case we won't be dicks about it, we won't blindly pretend that every function could use globals when they obviously don't."

> Heck, you'd get pretty far with a simple conservative yes/no on whether a function might touch any globals.

No, you wouldn't. Try writing such an analysis. Either I will be able to break your analysis or it will return "yes, this might mutate a global" for so much of any reasonably sized program that the analysis will be useless.

This is basic, basic stuff to anyone who is in the sound static analysis field.

> Either I will be able to break your analysis or it will return "yes, this might mutate a global" for so much of any reasonably sized program that the analysis will be useless.

The point is, you can write functioning programs even with that -- you can copy construct out of a global, for example, but you obviously can't pass string literals to functions that touch stdout or errno. If you want to make a legitimate disagreement, argue against the more practical version where you treat different global variables as different things.

> This is basic, basic stuff to anyone who is in the sound static analysis field.

Do people in that field also nitpick pieces of rhetoric and deliberately ignore the main point?

I don't think any intelligent person in that field would argue that C++ programs can't be written or refactored in such a way so as to get rigid enough use of globals so as to pass a relatively conservative analysis. I mean, that would imply you couldn't get anything useful done in a language without globals.

> The point is, you can write functioning programs even with that -- you can copy construct out of a global

Copy construction out of a global is actually still unsafe, because some other thread (for example) might mutate the global, invalidating the this pointer. Or the copy constructor might call a function that can't be proven to not access the global, causing the same problem.

> If you want to make a legitimate disagreement, argue against the more practical version where you treat different global variables as different things.

That isn't meaningfully more precise. You are still going to require higher order control flow analysis. Think about how you would analyze functions like std::transform() and prove that the function passed in doesn't destroy the container being mapped over (or call a function that does, etc.)

> I don't think any intelligent person in that field would argue that C++ programs can't be written or refactored in such a way so as to get rigid enough use of globals so as to pass a relatively conservative analysis. I mean, that would imply you couldn't get anything useful done in a language without globals.

Well, sure, but that's not C++ anymore. Neither roc nor I have argued that you can't write some subset of C++ that is sound. In fact, there are subsets of C used for avionics and the like that are provably type-safe and memory-safe, because they disallow dynamic allocation entirely and are extremely restrictive with what pointer operations they support. But the entire value proposition of these C++ static analyses is to be compatible with the C++ ecosystem. When you start adding restrictions that rule out most C++ libraries and, worse, that you can't get around without massively rewriting their logic, then you're essentially a different language.

> Copy construction out of a global is actually still unsafe, because some other thread (for example) might mutate the global, invalidating the this pointer.

It's not unsafe, that code wouldn't pass the check. Other threads would have to not access globals at all, or all threads have to access them read-only.

As for doing things on a variable by variable basis, just imagine a rote refactoring from a global variable to non-global variable passed up from main. For example:

https://github.com/srh/memcached/compare/65da75f...235db6

We eliminate the global variable "as" by passing a struct assoc pointer parameter up from main.

The parts of this that isn't a rote refactoring is where, instead of adding another parameter to functions like event_handler and event_set, modifying libevent to pass through the struct assoc pointer, we instead put the struct assoc pointer into a closure (because this is C, whatever homespun kludge is most convenient). The other situation where it's put into a closure is some calls to pthread_create.

We know that this refactoring retains identical behavior -- every access to the global as now accesses the same as object -- because only one instance of struct assoc has been constructed. (And the kludges with C-style closures here are correct merely by inspection, i.e. the right variables are initialized, type safety would handle that.)

Now, if we have some tool for checking use of globals, it can do the same thing, and then analyze memory safety using the rules it uses for non-globals. What it needs from the user are annotations to help it know when and how a global reference should be captured by a closure instead of passed as an extra parameter to the closure. Of course, it would be perfectly valid to thread a struct assoc pointer parameter through the internals of libevent, if that was sufficient to check the program.

Now, memcached would have other problems to deal with, because the struct assoc is shared across threads. The point is, the problem is not that it's a global variable, it's other structure inherent to how the program is designed. And examples like

    unique_ptr<Foo> p;
    void bar() {
      p = make_unique<Foo>(...);
      Foo xyz(*p); // Forbidden! (NOT)
    }

are easily dealt with.