4 ms·

I think the evidence outweighs opinions, and I think the evidence says that it is hard to avoid memory management problems in C++.

FpUser 5y ago
I do not have single explicit memory management call in my product of very decent size written in modern C++. So no , I have no idea where did you fish your "evidence" from.
- dan-robertson 5y ago
  I don’t understand what you’re trying to say? Do you mean that you don’t call malloc? Because that is totally not the point. For example, you could create a new object, pass a reference to it to some function that stores it in a hash table, reach the end of your function where the object is automatically deleted, and then have something try to read the object out of the hashtable. Nowhere do you need to call malloc or do any explicit memory management and yet you have a use-after-free bug. Some evidence can be found in my reply to the sibling comment which talks about chrome, a large and very well-tested C++ application mostly in a modern style. There are also surveys of security vulnerabilities that find a large percentage are due to incorrect memory management. Maybe I’m just missing the point though as I think I’m only writing obvious well-known things and you probably mean something more nuanced?
  - FpUser 5y ago
    >"For example, you could create a new object, pass a reference to it to some function that stores it in a hash table, reach the end of your function where the object is automatically deleted, and then have something try to read the object out of the hashtable." Emplace constructs copy of object in the container. You should be fine.
    - dan-robertson 5y ago
      What are you trying to argue here? I’m not claiming that the thing I described is good, only that it is a way to get memory management wrong without calling malloc, so the fact that emplace exists is irrelevant. I think I still don’t understand what your point is because you seem to be arguing against something I’m not claiming.
      - FpUser 5y ago
        If you are actively looking to shoot yourself in a foot be my guest. But it is your problem, not the one of the language.
  - jstimpfle 5y ago
    In your example, storing a pointer to an item in the hashtable in a context that potentially outlives the hashtable items could qualify as "bad memory management". Long-lived cross-context pointers in general I frown upon (most pointers I use have their lifetime bound to a function call), although there are no hard rules of course, and you have a point in that these errors are not detected by most type systems or probably even static analyzers. Well, it's still a smell, because we know these types of problems and we know many ways to avoid most of them. I'm saying this all to support the claim that memory management needn't be hard, not to claim that there aren't any exploitable memory bugs out there, which would be an insane claim.
- pjmlp 5y ago
  Grep AOSP source code then.
  - FpUser 5y ago
    WTF is AOSP and why would I grep it?
    - ncmncm 5y ago
      AOSP is an ancient collection of Android apps Google published.
      - FpUser 5y ago
        Well however good / bad their code is is not my problem. I see no reason for me looking at it.
        ncmncm 5y ago
        Except as an object lesson. But we all have read more than our share of bad code already.
        pjmlp 5y ago
        As a lesson that ISO C++ contributions are themselves not an example of the kind of code shown at CppCon talks.
      - pjmlp 5y ago
        Wrong, it is the current version of public source for Android, including version 12.
    - pjmlp 5y ago
      The public source code for Android, written by a company that seats on ISO C++.
zarkov99 5y ago
I think it depends a lot on experience and wether the code base is post C++ 11. Modern codebases like clang or chrome do not seem to have any more memory management issues than something like Intellij. Personally I wrote system software in C++ for 10 years and memory management was a problem maybe once or twice.
- dan-robertson 5y ago
  > chrome See https://www.cvedetails.com/vulnerability-list/vendor_id-1224/product_id-15031/opec-1/Google-Chrome.html https://www.cvedetails.com/vulnerability-list/vendor_id-1224... for a list of RCE vulnerabilities. I see a bunch of memory management problems there. Also note that chrome is likely much better tested than some other C++ project, and lots of tools are used to search for potential vulnerabilities or invalid memory use as well as fuzzing and crash reports from a large install base. I don’t know how this compares with IntelliJ/Java (which I also don’t particularly like). I would expect other C++ applications to have a higher defect rate than chrome due to less testing/tooling but also likely a lower attack surface area.
  - jstimpfle 5y ago
    Never contain programs so few bugs, as when no debugging tools are available - Niklaus Wirth Fuzzers and testing can detect bugs but I don't see how they can make a contribution to a reasonable software structure (I believe that bad structure is the prime cause of bugs).
    - dan-robertson 5y ago
      The other tools being talked about are static analysis tools or runtime instrumentation both designed specifically to try to find bad memory use patterns. I don’t mean this in a rude way, but I don’t care what you believe, because the thing I care about is evidence. If you have some actual evidence for your claim, I would be interested. (I also believe there can be improvements from better code structure in a rewrite and this can make up for a significant portion of the improvements from a ‘let’s rewrite it all in rust’ project).

FpUser 5y ago

I do not have single explicit memory management call in my product of very decent size written in modern C++. So no , I have no idea where did you fish your "evidence" from.

dan-robertson 5y ago
I don’t understand what you’re trying to say? Do you mean that you don’t call malloc? Because that is totally not the point. For example, you could create a new object, pass a reference to it to some function that stores it in a hash table, reach the end of your function where the object is automatically deleted, and then have something try to read the object out of the hashtable. Nowhere do you need to call malloc or do any explicit memory management and yet you have a use-after-free bug. Some evidence can be found in my reply to the sibling comment which talks about chrome, a large and very well-tested C++ application mostly in a modern style. There are also surveys of security vulnerabilities that find a large percentage are due to incorrect memory management. Maybe I’m just missing the point though as I think I’m only writing obvious well-known things and you probably mean something more nuanced?
- FpUser 5y ago
  >"For example, you could create a new object, pass a reference to it to some function that stores it in a hash table, reach the end of your function where the object is automatically deleted, and then have something try to read the object out of the hashtable." Emplace constructs copy of object in the container. You should be fine.
  - dan-robertson 5y ago
    What are you trying to argue here? I’m not claiming that the thing I described is good, only that it is a way to get memory management wrong without calling malloc, so the fact that emplace exists is irrelevant. I think I still don’t understand what your point is because you seem to be arguing against something I’m not claiming.
    - FpUser 5y ago
      If you are actively looking to shoot yourself in a foot be my guest. But it is your problem, not the one of the language.
- jstimpfle 5y ago
  In your example, storing a pointer to an item in the hashtable in a context that potentially outlives the hashtable items could qualify as "bad memory management". Long-lived cross-context pointers in general I frown upon (most pointers I use have their lifetime bound to a function call), although there are no hard rules of course, and you have a point in that these errors are not detected by most type systems or probably even static analyzers. Well, it's still a smell, because we know these types of problems and we know many ways to avoid most of them. I'm saying this all to support the claim that memory management needn't be hard, not to claim that there aren't any exploitable memory bugs out there, which would be an insane claim.
pjmlp 5y ago
Grep AOSP source code then.
- FpUser 5y ago
  WTF is AOSP and why would I grep it?
  - ncmncm 5y ago
    AOSP is an ancient collection of Android apps Google published.
    - FpUser 5y ago
      Well however good / bad their code is is not my problem. I see no reason for me looking at it.
      - ncmncm 5y ago
        Except as an object lesson. But we all have read more than our share of bad code already.
        pjmlp 5y ago
        As a lesson that ISO C++ contributions are themselves not an example of the kind of code shown at CppCon talks.
    - pjmlp 5y ago
      Wrong, it is the current version of public source for Android, including version 12.
  - pjmlp 5y ago
    The public source code for Android, written by a company that seats on ISO C++.

zarkov99 5y ago

I think it depends a lot on experience and wether the code base is post C++ 11. Modern codebases like clang or chrome do not seem to have any more memory management issues than something like Intellij. Personally I wrote system software in C++ for 10 years and memory management was a problem maybe once or twice.

dan-robertson 5y ago
> chrome See https://www.cvedetails.com/vulnerability-list/vendor_id-1224/product_id-15031/opec-1/Google-Chrome.html https://www.cvedetails.com/vulnerability-list/vendor_id-1224... for a list of RCE vulnerabilities. I see a bunch of memory management problems there. Also note that chrome is likely much better tested than some other C++ project, and lots of tools are used to search for potential vulnerabilities or invalid memory use as well as fuzzing and crash reports from a large install base. I don’t know how this compares with IntelliJ/Java (which I also don’t particularly like). I would expect other C++ applications to have a higher defect rate than chrome due to less testing/tooling but also likely a lower attack surface area.
- jstimpfle 5y ago
  Never contain programs so few bugs, as when no debugging tools are available - Niklaus Wirth Fuzzers and testing can detect bugs but I don't see how they can make a contribution to a reasonable software structure (I believe that bad structure is the prime cause of bugs).
  - dan-robertson 5y ago
    The other tools being talked about are static analysis tools or runtime instrumentation both designed specifically to try to find bad memory use patterns. I don’t mean this in a rude way, but I don’t care what you believe, because the thing I care about is evidence. If you have some actual evidence for your claim, I would be interested. (I also believe there can be improvements from better code structure in a rewrite and this can make up for a significant portion of the improvements from a ‘let’s rewrite it all in rust’ project).