5 ms·

I'm sorry, but C++ does not exactly have a culture of secure, maintainable and understandable software.

pjmlp 10y ago
Yes, it does. The majority of C++ programmers make use of: - RAII - String classes instead of char* überall - Vector classes instead of char* überall - new and delete instead of malloc()/free() and casts - References for out parameters instead of pointers - Real enums, specially since C++11, instead of #define - Smart pointers for memory management - Type based programming to reduce errors - Minimize the use of the pre-processor to #include and macros, only when they cannot be expressed via templates, const, constexpr and inline. Most of the unsafe C++ code is written by the "C with C++" sub-community that are mostly C refugees forced to use a C++ compiler. Also while the C++ community is pushing for safety with activities like the C++ Core Guidelines and reducing the amount of UB in the standard, the C standard community doesn't care at all. The only thing that the C community has done regarding security was the Annex K in C99, which was proven so good that it became an optional feature in C11.
- pcwalton 10y ago
  > Yes, it does. 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 majority of C++ programmers make use of: None of this, empirically, results in safe code. > Most of the unsafe C++ code is written by the "C with C++" sub-community that are mostly C refugees forced to use a C++ compiler. I haven't seen any evidence for this. A lot of vulnerabilities are found in modern C++11. > Also while the C++ community is pushing for safety with activities like the C++ Core Guidelines and reducing the amount of UB in the standard, the C standard community doesn't care at all. I don't see any way that the C++ Core Guidelines are going to be able to succeed in creating a usable language that is memory-safe. Robert O'Callahan and I have elaborated why in other posts.
  - pjmlp 10y ago
    > Where is this modern C++ culture that has resulted in large-scale codebases free of memory safety vulnerabilities? In any large scale C++ conference like CppCon. In tooling from Microsoft and Apple. > I haven't seen any evidence for this. A lot of vulnerabilities are found in modern C++11. Using C++11 idioms, or C with classes? > I don't see any way that the C++ Core Guidelines are going to be able to succeed in creating a usable language that is memory-safe. Robert O'Callahan and I have elaborated why in other posts. Rust will become a sound alternative to C++ when: - Libraries stop using nightly - Rust developers can call OS APIs like COM on Windows without gymnastics. I mean with the same ease that Delphi, C++ Builder and Visual C++ integrate with COM. - Rust developers can call OS X and iOS APIs with the same ease than Swift and Objective-C - Has IDE support that can match what QtCreator, Clion, XCode, Visual Studio, C++ Builder, Keil MDK, ... I really would like to see Rust one day supersede C++, but in what concerns C family of the languages, C++ is the safest option we currently have. I have been part of the C++ community since the early days as Turbo Pascal and strong type refugee, and have followed how hard it has been for a language that is almost copy-paste compatible with C to earn the position it holds in the industry. So until Rust gets some OS SDK love, bashing C++ community efforts to improve security won't get many adopters. I keep on playing with Rust, but I get to write production code it still is JVM, .NET languages, Swift or C++.
    - pcwalton 10y ago
      > In any large scale C++ conference like CppCon. > In tooling from Microsoft and Apple. Microsoft and Apple regularly ship memory safety vulnerabilities in their codebases that are written in modern C++. Their browser engines, for example. > Using C++11 idioms, or C with classes? Using C++11 idioms. C++11 doesn't actually do anything to mitigate use after free, for example. In fact, I think there's a reasonable argument to be made that C++11 is less safe than C++03 in terms of use after free, because of features like move semantics and lambdas. And I'm not intending to argue "use Rust" here. There are plenty of other memory safe languages out there. I'm simply arguing that C++ is not memory safe, and it cannot be while preserving any semblance of backwards compatibility. The specific technical reasons for this have been elaborated in posts that I've sure you've seen. I'd like to see proponents of the idea that modern C++ is memory safe actually try to rebut those.
- 1209091121 10y ago
  And yet, most of the Unix tools just work, which I cannot say of the average C++ program. Can you name one C++ program with the same track record as postfix or qmail?
  - prodigal_erik 10y ago
    qmail contained a buffer overflow that allowed remote root access, prevented only by having a low limit on available memory. http://web.archive.org/web/20160401021400/http://www.guninski.com/where_do_you_want_billg_to_go_today_4.html http://web.archive.org/web/20160401021400/http://www.guninsk... djb is a smart and motivated guy and even he isn't quite capable of writing correct C code; how much chance does anyone else have?
    - 10019310231 10y ago
      qmail is supposed to be used with "softlimit" from daemontools. All decent tutorials mention that. Again, which C++ program has been even analyzed to that level?
      - SamReidHughes 10y ago
        Did it ever occur to you that if a C++ programmer of security mindset wanted to make something like postfix or qmail, they'd just pick a language that was garbage collected?
        101291091 10y ago
        No, it did not occur to me. The reason is precisely that I have not seen this mindset among C++ programmers, at least in the open source world. Llvm is an exception. What I do see is hubris. They are overconfident and pretend that one can use C++ like Haskell, i.e. one can safely go ahead and pile one abstraction onto another. C programmers at least know the limitations of their language. This is the just impression that I and many others get. I'm sure there are counterexamples.

pjmlp 10y ago

Yes, it does. The majority of C++ programmers make use of: - RAII - String classes instead of char* überall - Vector classes instead of char* überall - new and delete instead of malloc()/free() and casts - References for out parameters instead of pointers - Real enums, specially since C++11, instead of #define - Smart pointers for memory management - Type based programming to reduce errors - Minimize the use of the pre-processor to #include and macros, only when they cannot be expressed via templates, const, constexpr and inline. Most of the unsafe C++ code is written by the "C with C++" sub-community that are mostly C refugees forced to use a C++ compiler. Also while the C++ community is pushing for safety with activities like the C++ Core Guidelines and reducing the amount of UB in the standard, the C standard community doesn't care at all. The only thing that the C community has done regarding security was the Annex K in C99, which was proven so good that it became an optional feature in C11.

pcwalton 10y ago
> Yes, it does. 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 majority of C++ programmers make use of: None of this, empirically, results in safe code. > Most of the unsafe C++ code is written by the "C with C++" sub-community that are mostly C refugees forced to use a C++ compiler. I haven't seen any evidence for this. A lot of vulnerabilities are found in modern C++11. > Also while the C++ community is pushing for safety with activities like the C++ Core Guidelines and reducing the amount of UB in the standard, the C standard community doesn't care at all. I don't see any way that the C++ Core Guidelines are going to be able to succeed in creating a usable language that is memory-safe. Robert O'Callahan and I have elaborated why in other posts.
- pjmlp 10y ago
  > Where is this modern C++ culture that has resulted in large-scale codebases free of memory safety vulnerabilities? In any large scale C++ conference like CppCon. In tooling from Microsoft and Apple. > I haven't seen any evidence for this. A lot of vulnerabilities are found in modern C++11. Using C++11 idioms, or C with classes? > I don't see any way that the C++ Core Guidelines are going to be able to succeed in creating a usable language that is memory-safe. Robert O'Callahan and I have elaborated why in other posts. Rust will become a sound alternative to C++ when: - Libraries stop using nightly - Rust developers can call OS APIs like COM on Windows without gymnastics. I mean with the same ease that Delphi, C++ Builder and Visual C++ integrate with COM. - Rust developers can call OS X and iOS APIs with the same ease than Swift and Objective-C - Has IDE support that can match what QtCreator, Clion, XCode, Visual Studio, C++ Builder, Keil MDK, ... I really would like to see Rust one day supersede C++, but in what concerns C family of the languages, C++ is the safest option we currently have. I have been part of the C++ community since the early days as Turbo Pascal and strong type refugee, and have followed how hard it has been for a language that is almost copy-paste compatible with C to earn the position it holds in the industry. So until Rust gets some OS SDK love, bashing C++ community efforts to improve security won't get many adopters. I keep on playing with Rust, but I get to write production code it still is JVM, .NET languages, Swift or C++.
  - pcwalton 10y ago
    > In any large scale C++ conference like CppCon. > In tooling from Microsoft and Apple. Microsoft and Apple regularly ship memory safety vulnerabilities in their codebases that are written in modern C++. Their browser engines, for example. > Using C++11 idioms, or C with classes? Using C++11 idioms. C++11 doesn't actually do anything to mitigate use after free, for example. In fact, I think there's a reasonable argument to be made that C++11 is less safe than C++03 in terms of use after free, because of features like move semantics and lambdas. And I'm not intending to argue "use Rust" here. There are plenty of other memory safe languages out there. I'm simply arguing that C++ is not memory safe, and it cannot be while preserving any semblance of backwards compatibility. The specific technical reasons for this have been elaborated in posts that I've sure you've seen. I'd like to see proponents of the idea that modern C++ is memory safe actually try to rebut those.
1209091121 10y ago
And yet, most of the Unix tools just work, which I cannot say of the average C++ program. Can you name one C++ program with the same track record as postfix or qmail?
- prodigal_erik 10y ago
  qmail contained a buffer overflow that allowed remote root access, prevented only by having a low limit on available memory. http://web.archive.org/web/20160401021400/http://www.guninski.com/where_do_you_want_billg_to_go_today_4.html http://web.archive.org/web/20160401021400/http://www.guninsk... djb is a smart and motivated guy and even he isn't quite capable of writing correct C code; how much chance does anyone else have?
  - 10019310231 10y ago
    qmail is supposed to be used with "softlimit" from daemontools. All decent tutorials mention that. Again, which C++ program has been even analyzed to that level?
    - SamReidHughes 10y ago
      Did it ever occur to you that if a C++ programmer of security mindset wanted to make something like postfix or qmail, they'd just pick a language that was garbage collected?
      - 101291091 10y ago
        No, it did not occur to me. The reason is precisely that I have not seen this mindset among C++ programmers, at least in the open source world. Llvm is an exception. What I do see is hubris. They are overconfident and pretend that one can use C++ like Haskell, i.e. one can safely go ahead and pile one abstraction onto another. C programmers at least know the limitations of their language. This is the just impression that I and many others get. I'm sure there are counterexamples.