4 ms·

What is wrong with C++? With POSIX semaphores, mutexes, and shared pointers, it is very rare to hit upon a memory issue in modern C++. Source: Writing code in

What is wrong with C++? With POSIX semaphores, mutexes, and shared pointers, it is very rare to hit upon a memory issue in modern C++. Source: Writing code in C/C++ for 30 years.

wat10000 1y ago
What a terrifying statement. Edit: to be less glib, this is like saying “our shred-o-matic is perfectly safe due to its robust and thoroughly tested off switch.” An off switch is essential but not nearly enough. It only provides acceptable safety if the operator is perfect, and people are not. You need guards and safety interlocks that ensure, for example, that the machine can’t be turned on while Bob is inside lubricating the bearings. Mutexes and smart pointers are important constructs but they don’t provide safety. Safety isn’t the presence of safe constructs, but the absence of unsafe ones. Smart pointers don’t save you when you manage to escape a reference beyond the lifetime of the object because C++ encourages passing parameters by reference all over the place. Mutexes and semaphores don’t save you from failing to realize that some shared state can be mutated on two threads simultaneously. And none of this saves you from indexing off the end of a vector. You can probably pick a subset of C++ that lets you write reasonably safe code. But the presence of semaphores, mutexes, and shared pointers isn’t what does it. Source: also writing C and C++ for 30 years.
- lisper 1y ago
  > Safety isn’t the presence of safe constructs, but the absence of unsafe ones. Exactly. Here is a data point: https://spinroot.com/spin/Doc/rax.pdf https://spinroot.com/spin/Doc/rax.pdf Tl;DR: This was software that ran on a spacecraft. Specifically designed to be safe, formally analyzed, and tested out the wazoo, but nonetheless failed in flight because someone did an end-run around the safe constructs to get something to work, which ended up producing a race condition.
- FpUser 1y ago
  >"What a terrifying statement." The statement may not be correct but calling it terrifying is way melodramatic.
  - wat10000 1y ago
    I don’t think so. The fact that someone with extensive experience thinks modern C++ is safe because it has semaphores and mutexes and smart pointers is legitimately scary. It’s not merely wrong, it reflects a fundamental misunderstanding of what the problem even is. It’s like an engineer designing airliners saying that they can be perfectly safe without any redundant systems because they have good wheels. That should have you backing away slowly while asking which manufacturer they work for.
    - FpUser 1y ago
      I think their statement amounts to something like in line of: subset of modern C++ and feature usage patterns can be reasonably safe and I am ok with it. Nothing is ever really safe of course. One should consider trade offs of quality / safety vs costs and make their own conclusion on where to lean more and where enough is enough.
      - wat10000 1y ago
        There's an argument to be made that you can write safe C++ by using the right subset of the modern language. It might even be a decent argument. But that's not the argument that was made here. They mentioned two things that have only the most tangential connection to security and that aren't even part of C++, plus one C++ feature that solves exactly one problem.
nesarkvechnep 1y ago
The worst code is usually written by someone who’s doing it for 30 years and can’t find a problem with their technology of choice. Especially with shared pointers you can encounter pretty terrible memory issues.
- kanbankaren 1y ago
  Dude, provide examples of "terrible" memory issues. Otherwise, you are just repeating the folklore which is outdated.
CharlesW 1y ago
> With POSIX semaphores, mutexes, and shared pointers, it is very rare to hit upon a memory issue in modern C++. There is a mountain of evidence (two examples follow) that this is not true. Roughly two-thirds of serious security bugs in large C++ products are still memory-safety violations. (1) https://msrc.microsoft.com/blog/2019/07/we-need-a-safer-systems-programming-language/ https://msrc.microsoft.com/blog/2019/07/we-need-a-safer-syst... (2) https://www.chromium.org/Home/chromium-security/memory-safety/ https://www.chromium.org/Home/chromium-security/memory-safet...
- kanbankaren 1y ago
  Show me a memory issue that was caused by proper usage of POSIX concurrency primitives.
  - jenadine 1y ago
    Proper usage is fine. The problem is that it is easy to make mistakes. The compiler won't tell you and you may not notice until too late in production, and it will take forever to debug.
  - kmeisthax 1y ago
    [dead]
  - CharlesW 1y ago
    Here's two: CVE-2021-33574, CVE-2023-6705. The former had to be fixed in glibc, illustrating that proper usage of POSIX concurrency primitives does nothing when the rest of the ecosystem is a minefield of memory safety issues. There are some good citations on page 6 of this NSA Software Memory Safety overview in case you're interested://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF
  - treyd 1y ago
    You're right, if you use the concurrency primitives properly you won't have data races. But the issue is when people don't use the concurrency primitives properly, which there is ample evidence for (posted in this thread) happening all the time. But with this argument, the response is "well they didn't use the primitives properly so the problem is them", which shifts the blame onto the developer and away from the tools which are too easy to silently misuse. This also ignores memory safety issues that aren't data races, like buffer overflows, UAF, etc.

What is wrong with C++? With POSIX semaphores, mutexes, and shared pointers, it is very rare to hit upon a memory issue in modern C++. Source: Writing code in C/C++ for 30 years.

wat10000 1y ago

What a terrifying statement. Edit: to be less glib, this is like saying “our shred-o-matic is perfectly safe due to its robust and thoroughly tested off switch.” An off switch is essential but not nearly enough. It only provides acceptable safety if the operator is perfect, and people are not. You need guards and safety interlocks that ensure, for example, that the machine can’t be turned on while Bob is inside lubricating the bearings. Mutexes and smart pointers are important constructs but they don’t provide safety. Safety isn’t the presence of safe constructs, but the absence of unsafe ones. Smart pointers don’t save you when you manage to escape a reference beyond the lifetime of the object because C++ encourages passing parameters by reference all over the place. Mutexes and semaphores don’t save you from failing to realize that some shared state can be mutated on two threads simultaneously. And none of this saves you from indexing off the end of a vector. You can probably pick a subset of C++ that lets you write reasonably safe code. But the presence of semaphores, mutexes, and shared pointers isn’t what does it. Source: also writing C and C++ for 30 years.

lisper 1y ago
> Safety isn’t the presence of safe constructs, but the absence of unsafe ones. Exactly. Here is a data point: https://spinroot.com/spin/Doc/rax.pdf https://spinroot.com/spin/Doc/rax.pdf Tl;DR: This was software that ran on a spacecraft. Specifically designed to be safe, formally analyzed, and tested out the wazoo, but nonetheless failed in flight because someone did an end-run around the safe constructs to get something to work, which ended up producing a race condition.
FpUser 1y ago
>"What a terrifying statement." The statement may not be correct but calling it terrifying is way melodramatic.
- wat10000 1y ago
  I don’t think so. The fact that someone with extensive experience thinks modern C++ is safe because it has semaphores and mutexes and smart pointers is legitimately scary. It’s not merely wrong, it reflects a fundamental misunderstanding of what the problem even is. It’s like an engineer designing airliners saying that they can be perfectly safe without any redundant systems because they have good wheels. That should have you backing away slowly while asking which manufacturer they work for.
  - FpUser 1y ago
    I think their statement amounts to something like in line of: subset of modern C++ and feature usage patterns can be reasonably safe and I am ok with it. Nothing is ever really safe of course. One should consider trade offs of quality / safety vs costs and make their own conclusion on where to lean more and where enough is enough.
    - wat10000 1y ago
      There's an argument to be made that you can write safe C++ by using the right subset of the modern language. It might even be a decent argument. But that's not the argument that was made here. They mentioned two things that have only the most tangential connection to security and that aren't even part of C++, plus one C++ feature that solves exactly one problem.

nesarkvechnep 1y ago

The worst code is usually written by someone who’s doing it for 30 years and can’t find a problem with their technology of choice. Especially with shared pointers you can encounter pretty terrible memory issues.

kanbankaren 1y ago
Dude, provide examples of "terrible" memory issues. Otherwise, you are just repeating the folklore which is outdated.

CharlesW 1y ago

> With POSIX semaphores, mutexes, and shared pointers, it is very rare to hit upon a memory issue in modern C++. There is a mountain of evidence (two examples follow) that this is not true. Roughly two-thirds of serious security bugs in large C++ products are still memory-safety violations. (1) https://msrc.microsoft.com/blog/2019/07/we-need-a-safer-systems-programming-language/ https://msrc.microsoft.com/blog/2019/07/we-need-a-safer-syst... (2) https://www.chromium.org/Home/chromium-security/memory-safety/ https://www.chromium.org/Home/chromium-security/memory-safet...

kanbankaren 1y ago
Show me a memory issue that was caused by proper usage of POSIX concurrency primitives.
- jenadine 1y ago
  Proper usage is fine. The problem is that it is easy to make mistakes. The compiler won't tell you and you may not notice until too late in production, and it will take forever to debug.
- kmeisthax 1y ago
  [dead]
- CharlesW 1y ago
  Here's two: CVE-2021-33574, CVE-2023-6705. The former had to be fixed in glibc, illustrating that proper usage of POSIX concurrency primitives does nothing when the rest of the ecosystem is a minefield of memory safety issues. There are some good citations on page 6 of this NSA Software Memory Safety overview in case you're interested://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF
- treyd 1y ago
  You're right, if you use the concurrency primitives properly you won't have data races. But the issue is when people don't use the concurrency primitives properly, which there is ample evidence for (posted in this thread) happening all the time. But with this argument, the response is "well they didn't use the primitives properly so the problem is them", which shifts the blame onto the developer and away from the tools which are too easy to silently misuse. This also ignores memory safety issues that aren't data races, like buffer overflows, UAF, etc.