News for hackers. Stuff that matters.

A comment on Why you should, actually, rewrite some of it in Rust. Parent comment

Re:Why you should, actually, rewrite some of it in Rust by blub on Wednesday July 12, 2017 @04:06PM (#14756157)
I'd be happy to discuss an example, because right now the idea that smart pointers are opaque about destruction is unfortunately too abstract for me to give a helpful reply to.
[ Parent | on HN ]
Re:Why you should, actually, rewrite some of it in Rust by pcwalton on Wednesday July 12, 2017 @04:58PM (#14756622)
Consider situations like this: https://stackoverflow.com/questions/17362673/temporary-lifet...

It's undefined behavior, despite not calling free anywhere. Replace with std::string and it could be use after free. In C, UAF wouldn't happen that silently for heap memory.

[ Parent | on HN ]
Re:Why you should, actually, rewrite some of it in Rust by blub on Thursday July 13, 2017 @03:31AM (#14759413)
A similar example was posted by matthieu_m on Reddit a while back, but that's still not worse than C, even if it's an unfortunate gap in compiler diagnostics.

From my POV compilers should warn that this code is potentially dangerous. My rule is: never return a reference or pointer from a function to something whose lifetime you don't have control of.

[ Parent | on HN ]
Re:Why you should, actually, rewrite some of it in Rust by pcwalton on Thursday July 13, 2017 @05:03AM (#14759802)
It's worse than C because you can't have UAF in C without explicitly calling free (or a function that transitively calls free). In C++ freeing is implicit.
[ Parent | on HN ]