3 ms·

> Robert O'Callahan and I have elaborated why in other posts. One point of note is that O'Callahan's "Vapourware" post points out a problem that's solvable, it

> Robert O'Callahan and I have elaborated why in other posts. 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. Your comment 162 days ago describes the real problem, or at least one of them. Edit, because fuck: > Where is this modern C++ culture that has resulted in large-scale codebases free of memory safety vulnerabilities? I've never seen even one, much less a "widespread culture". 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? Why even bother replying, if you're going to drag the discussion into some corner like that?

pcwalton 10y ago
> 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.
- SamReidHughes 10y ago
  > 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.
  - pcwalton 10y ago
    > 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.
    - SamReidHughes 10y ago
      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."
      - pcwalton 10y ago
        > 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.

pcwalton 10y ago

> 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.

SamReidHughes 10y ago
> 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.
- pcwalton 10y ago
  > 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.
  - SamReidHughes 10y ago
    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."
    - pcwalton 10y ago
      > 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.