by itissid on 2/19/25, 12:26 PM with 2 comments
I suddenly thought of the forward looking trajectory of the idea of making c++ compiler smart(er) as to ease the burden of memory copying (section 3) with zero overhead. If one traces this arc it means that one day c++ compilers would be equivalent to the borrow checker? That is to say they would throw compile time errors for using some construct in c++ that copied instead of moved?
by ActorNightly on 2/19/25, 11:11 PM
Alternatively, if you want to work at a low level, all you would really need to do is make malloc and free smarter, because "memory unsafe" code is basically a case of double free in 99% of the time, as other things are either covered for by existing things like stack canaries, non executable memory sections, retpolines that protect against ROP chains, and so on. So just making sure that when free is called, it actually has permission to deallocate the chunk is all you need. You can do some of that statically, but to fully cover it, you would have some more arguments to the malloc and free call that establish permissions.
As an aside, the latter is why Rust doesn't really have a future. Its just popular enough these days to where its seen as taboo to hate on it because "memory safety", but the reality is, most of the existing well written C/C++ code is memory safe through very basic structuring of programs, and without the cumbersome syntax of Rust borrow checking that allows dev to happen much faster, considering any large codebase in Rust has a shitload of unsafes scattered about due to need to interact with posix libraries.
by steveklabnik on 2/20/25, 12:33 AM
The committee basically turned it down.