4 ms·

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

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.

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.