5 ms·

> C++ does sort of have a safe subset. I see this claim all the time, but can you give some examples of large C++ projects that don't constantly struggle with

> C++ does sort of have a safe subset. I see this claim all the time, but can you give some examples of large C++ projects that don't constantly struggle with memory safety issues? (And are looking for them, of course.)

pjmlp 6y ago
The problem is enforcing that safe subset. It only works when everyone plays balls and doesn't do C style coding, ever. Usually that can work in small teams with security minded individuals but it isn't a given. And then there is the little fact that on most surveys, the amount of answers referring any kind of static analysis tooling are usually around 50%. What C++ has definitely going for it, is having the type system tools to write much safer code than plain old C. However its copy-paste compatibility with C is also what hinders any attempt to force people to actually only use those better features. The only way to fix this is having systems programming languages being adopted that aren't C at copy-paste level. Other would be some kind of Safe C, but both WG14 and C community in general have voted against such improvements.
- josteink 6y ago
  > It only works when everyone plays balls and doesn't do C style coding, ever. If that’s the problem, and solving that would solve all of C++s memory-issues, why have no-one made a compiler option to simply make that code illegal? A -EUNSAFE or whatever?
  - pjmlp 6y ago
    Because what got C++ adopted in first place was its copy-paste compatibility with C. C++ was also born at Bell Labs, and due to that, all major C compiler vendors quickly started shipping C++ on their boxes as well. If you take away copy-paste compatibility you might be better off doing D, C# or whatever safe variant already exists. Which is what many of us have done, to move to type safe languages, and only use C and C++ at the boundaries, in small pockets of unsafe code. In fact if you look at mobile OSes, that is the reality for app developers, C and C++ are no longer the full stack languages they were 20 years ago, rather used for the kernel, drivers, compositor and shading languages, but everything else happens in safer languages. And the SDKs only allow you to write libraries, not full applications. Naturally are clever developers that subvert the workflow and transform the libraries into the actual application.
  - the_why_of_y 6y ago
    Because this would refuse to compile 100% of real-world C++ code, so nobody would use it. One problem is that C++ can directly include C headers of the operating system, while languages that aren't copy-paste compatible with C have to create some kind of wrapper library for them... this is a major reason for the success of C++, but it also makes improvements of this kind far harder to deploy in practice.
    - josteink 6y ago
      > Because this would refuse to compile 100% of real-world C++ code, so nobody would use it. So if anyone is claiming you could write real-world safe C++ if you wanted to, they are making a false claim then?
      - the_why_of_y 6y ago
        I think you'd have to do the same thing that you'd do in non-C++ languages: write an abstraction layer that encapsulates the low-level OS access (or hardware access, in embedded software) and whose implementation is unsafe, but whose interface is "safe", whatever that means. Once you have that to build on top of, such a compiler flag could make sense... if it were possible in C++, which I'm not sure about. See for example this criticism of one such effort: https://robert.ocallahan.org/2016/06/safe-c-subset-is-vapourware.html https://robert.ocallahan.org/2016/06/safe-c-subset-is-vapour...
        josteink 6y ago
        So in about half a decade the C++ camp has made no improvements wrt to tooling and statically verified safe code, it’s been all talk and no show. And in the meantime Rust has improved massively. It’s obviously still too early to declare a winner, but to me this sounds like a turtle slowly but surely overtaking a rabbit.
  - anlp1kk 6y ago
    Because you would make many proven algorithms from Knuth or CLRS illegal. This is never acknowledged by the C++ people: Idiomatic C++ is not suitable for formal proofs, if you don't believe me, ask Xavier Leroy.
- anlq100 6y ago
  It has nothing to do with C style coding. The worst offenders are the latest and greatest features, as described brilliantly in this very thread: https://news.ycombinator.com/item?id=23290030 https://news.ycombinator.com/item?id=23290030 I would argue that the closer you stay to C while using the good features of C++, the safer the code is. And obviously well written and debugged C code is nearly always more robust than C++ code. But for ideological reasons most people here are unable to acknowledge that, perhaps because they cannot do it.
  - pjmlp 6y ago
    Quite on the contrary, the worst offenders are: - implicit conversions - decays from enums to integers - implicit conversiosn from integers to unexisting enums - no bounds checking - implicit conversions between pointers and arrays - no proper way to ensure a given array length is valid as part of a function parameter - null terminated strings, that occasionally aren't terminated - abusing null terminated strings with clever algorithms, e.g. strtok() - the preprocessor - const that isn't really const - variable arguments that require getting the macro type arguments - UB explored to the last possibility of code optimization - no safe way to deal with output parameters - typedef don't introduce strong typing All of that came from C, not C++.
    - why_bother100 6y ago
      > implicit conversions Manageable in C. Integer conversions are only a tiny fraction of all the other implicitness in C++. > decays from enums to integers Compiler warns. Recent real compilers like gcc even have exhaustiveness checks like OCaml. > implicit conversions from integers to unexisting enums. Compiler warns. - no bounds checking Reason about that and implement your own scheme. Or prove. > implicit conversions between pointers and arrays Have not seen a single bug due to that in more than 1000000 lines of C. > null terminated strings, that occasionally aren't terminated Have not seen a bug due to that, this is the canonical example of an overblown hypothetical threat. > abusing null terminated strings with clever algorithms, e.g. strtok() Prove the algorithm or don't use it. Hint: As far as proofs are concerned, NUL terminated strings are like Lisp lists terminated with NIL, hence a well-founded data structure that is easily amenable to proofs (unlike C++ constructs). - the preprocessor Rarely introduces anything and is still required for C++, especially in sane test suites. I don't think all that came from C, things like typedef being an alias rather than a separate type seem much older. You are again just throwing dirt at C, mocking all people who write actually robust buzzword free software. You are ignoring that C code is much easier for formal proofs that C++ code (the kind that you advocate).
jandrewrogers 6y ago
I design high-scale database kernels, large code bases, written in modern C++. I can’t remember the last time we had a memory safety issue. It isn’t as though we don’t have plenty of bugs during development, just not those kinds of bugs. Competent idiomatic code simply doesn’t leave much room for those kinds of bugs to occur. If you “constantly struggle with memory safety issues”, you are doing something fundamentally wrong. That’s not something you can blame on the language. I am always baffled by the people that supposedly write modern C++ professionally and constantly have memory safety issues. Most serious projects won’t hire you if you aren’t capable of writing memory safe code in your sleep, it is a basic skill.
- AaronFriel 6y ago
  Is it possible that you haven't found memory safety issues because you haven't been looking for them, haven't been fuzz testing, or haven't had adversarial users of your codebases?
  - jandrewrogers 6y ago
    These are database kernels used for mission-critical things with extreme workload profiles. It has to survive longevity testing at saturating workloads with continuous fault injection. If there were memory safety issues, I think someone would have noticed by now. The reality is that there isn’t much opportunity for memory safety issues to occur anyway, the type system and scheduler do most of the heavy lifting. Similarly, concurrency safety isn’t much of an issue because threads barely interact. Most high-performance server software looks this way these days. Bugs tend to be of the boring logic variety that can happen in any programming language.
    - AaronFriel 6y ago
      > These are database kernels used for mission-critical things with extreme workload profiles. > Similarly, concurrency safety isn’t much of an issue because threads barely interact. I think the domain you're working in isn't as susceptible to memory safety issues, but that doesn't mean they're not present. It also sounds like they domain you're working in is trivially parallelized if threads "barely interact", which limits your exposure to those memory and data race issues. If you gave an adversary access to the API of your kernel however, how long do you think before they found a use-after-free, double-free, stack or heap overflow, etc? Days, weeks, or hours? If you haven't run a fuzzer yet, I wouldn't be so confident.

pjmlp 6y ago

The problem is enforcing that safe subset. It only works when everyone plays balls and doesn't do C style coding, ever. Usually that can work in small teams with security minded individuals but it isn't a given. And then there is the little fact that on most surveys, the amount of answers referring any kind of static analysis tooling are usually around 50%. What C++ has definitely going for it, is having the type system tools to write much safer code than plain old C. However its copy-paste compatibility with C is also what hinders any attempt to force people to actually only use those better features. The only way to fix this is having systems programming languages being adopted that aren't C at copy-paste level. Other would be some kind of Safe C, but both WG14 and C community in general have voted against such improvements.

josteink 6y ago
> It only works when everyone plays balls and doesn't do C style coding, ever. If that’s the problem, and solving that would solve all of C++s memory-issues, why have no-one made a compiler option to simply make that code illegal? A -EUNSAFE or whatever?
- pjmlp 6y ago
  Because what got C++ adopted in first place was its copy-paste compatibility with C. C++ was also born at Bell Labs, and due to that, all major C compiler vendors quickly started shipping C++ on their boxes as well. If you take away copy-paste compatibility you might be better off doing D, C# or whatever safe variant already exists. Which is what many of us have done, to move to type safe languages, and only use C and C++ at the boundaries, in small pockets of unsafe code. In fact if you look at mobile OSes, that is the reality for app developers, C and C++ are no longer the full stack languages they were 20 years ago, rather used for the kernel, drivers, compositor and shading languages, but everything else happens in safer languages. And the SDKs only allow you to write libraries, not full applications. Naturally are clever developers that subvert the workflow and transform the libraries into the actual application.
- the_why_of_y 6y ago
  Because this would refuse to compile 100% of real-world C++ code, so nobody would use it. One problem is that C++ can directly include C headers of the operating system, while languages that aren't copy-paste compatible with C have to create some kind of wrapper library for them... this is a major reason for the success of C++, but it also makes improvements of this kind far harder to deploy in practice.
  - josteink 6y ago
    > Because this would refuse to compile 100% of real-world C++ code, so nobody would use it. So if anyone is claiming you could write real-world safe C++ if you wanted to, they are making a false claim then?
    - the_why_of_y 6y ago
      I think you'd have to do the same thing that you'd do in non-C++ languages: write an abstraction layer that encapsulates the low-level OS access (or hardware access, in embedded software) and whose implementation is unsafe, but whose interface is "safe", whatever that means. Once you have that to build on top of, such a compiler flag could make sense... if it were possible in C++, which I'm not sure about. See for example this criticism of one such effort: https://robert.ocallahan.org/2016/06/safe-c-subset-is-vapourware.html https://robert.ocallahan.org/2016/06/safe-c-subset-is-vapour...
      - josteink 6y ago
        So in about half a decade the C++ camp has made no improvements wrt to tooling and statically verified safe code, it’s been all talk and no show. And in the meantime Rust has improved massively. It’s obviously still too early to declare a winner, but to me this sounds like a turtle slowly but surely overtaking a rabbit.
- anlp1kk 6y ago
  Because you would make many proven algorithms from Knuth or CLRS illegal. This is never acknowledged by the C++ people: Idiomatic C++ is not suitable for formal proofs, if you don't believe me, ask Xavier Leroy.
anlq100 6y ago
It has nothing to do with C style coding. The worst offenders are the latest and greatest features, as described brilliantly in this very thread: https://news.ycombinator.com/item?id=23290030 https://news.ycombinator.com/item?id=23290030 I would argue that the closer you stay to C while using the good features of C++, the safer the code is. And obviously well written and debugged C code is nearly always more robust than C++ code. But for ideological reasons most people here are unable to acknowledge that, perhaps because they cannot do it.
- pjmlp 6y ago
  Quite on the contrary, the worst offenders are: - implicit conversions - decays from enums to integers - implicit conversiosn from integers to unexisting enums - no bounds checking - implicit conversions between pointers and arrays - no proper way to ensure a given array length is valid as part of a function parameter - null terminated strings, that occasionally aren't terminated - abusing null terminated strings with clever algorithms, e.g. strtok() - the preprocessor - const that isn't really const - variable arguments that require getting the macro type arguments - UB explored to the last possibility of code optimization - no safe way to deal with output parameters - typedef don't introduce strong typing All of that came from C, not C++.
  - why_bother100 6y ago
    > implicit conversions Manageable in C. Integer conversions are only a tiny fraction of all the other implicitness in C++. > decays from enums to integers Compiler warns. Recent real compilers like gcc even have exhaustiveness checks like OCaml. > implicit conversions from integers to unexisting enums. Compiler warns. - no bounds checking Reason about that and implement your own scheme. Or prove. > implicit conversions between pointers and arrays Have not seen a single bug due to that in more than 1000000 lines of C. > null terminated strings, that occasionally aren't terminated Have not seen a bug due to that, this is the canonical example of an overblown hypothetical threat. > abusing null terminated strings with clever algorithms, e.g. strtok() Prove the algorithm or don't use it. Hint: As far as proofs are concerned, NUL terminated strings are like Lisp lists terminated with NIL, hence a well-founded data structure that is easily amenable to proofs (unlike C++ constructs). - the preprocessor Rarely introduces anything and is still required for C++, especially in sane test suites. I don't think all that came from C, things like typedef being an alias rather than a separate type seem much older. You are again just throwing dirt at C, mocking all people who write actually robust buzzword free software. You are ignoring that C code is much easier for formal proofs that C++ code (the kind that you advocate).

jandrewrogers 6y ago

I design high-scale database kernels, large code bases, written in modern C++. I can’t remember the last time we had a memory safety issue. It isn’t as though we don’t have plenty of bugs during development, just not those kinds of bugs. Competent idiomatic code simply doesn’t leave much room for those kinds of bugs to occur. If you “constantly struggle with memory safety issues”, you are doing something fundamentally wrong. That’s not something you can blame on the language. I am always baffled by the people that supposedly write modern C++ professionally and constantly have memory safety issues. Most serious projects won’t hire you if you aren’t capable of writing memory safe code in your sleep, it is a basic skill.

AaronFriel 6y ago
Is it possible that you haven't found memory safety issues because you haven't been looking for them, haven't been fuzz testing, or haven't had adversarial users of your codebases?
- jandrewrogers 6y ago
  These are database kernels used for mission-critical things with extreme workload profiles. It has to survive longevity testing at saturating workloads with continuous fault injection. If there were memory safety issues, I think someone would have noticed by now. The reality is that there isn’t much opportunity for memory safety issues to occur anyway, the type system and scheduler do most of the heavy lifting. Similarly, concurrency safety isn’t much of an issue because threads barely interact. Most high-performance server software looks this way these days. Bugs tend to be of the boring logic variety that can happen in any programming language.
  - AaronFriel 6y ago
    > These are database kernels used for mission-critical things with extreme workload profiles. > Similarly, concurrency safety isn’t much of an issue because threads barely interact. I think the domain you're working in isn't as susceptible to memory safety issues, but that doesn't mean they're not present. It also sounds like they domain you're working in is trivially parallelized if threads "barely interact", which limits your exposure to those memory and data race issues. If you gave an adversary access to the API of your kernel however, how long do you think before they found a use-after-free, double-free, stack or heap overflow, etc? Days, weeks, or hours? If you haven't run a fuzzer yet, I wouldn't be so confident.