6 ms·
Someone would need to make the case for them. AFAIK neither Ada nor BetterC prevent memory safety bugs like Rust does... for example it appears neither of them
by roca 7y ago
Someone would need to make the case for them.
AFAIK neither Ada nor BetterC prevent memory safety bugs like Rust does... for example it appears neither of them prevent use-after-free of dynamic heap allocations, a pretty common sort of exploitable memory safety bug.
- gmueckl 7y agoAll that Rust does wrt to that is to enforce reference counting overhead. That has well known issues and limitations and is not very attractive, either.
- jhomedall 7y agoThe only types in the Rust standard library that do reference counting are `Rc` and `Arc` (which are both implemented in Rust). Borrow checking is done statically.
- gmueckl 7y agoBut borrow checking doesn't cover heap allocations.
- jcranmer 7y agoYes it does. Borrow guarantees that the lifetime of the borrower does not exceed the lifetime can provide. Heap allocations have a lifetime--the start of a Box<> is the call to malloc, and the end is the call to free. Borrow checking prevents you from using the value after the free.
- geofft 7y agoHuh? It absolutely does, you can store a Box<T> somewhere and get multiple &'a Ts out of it, where 'a is limited to the lifetime of the box, but only one &'a mut T out of it at once.
- gmueckl 7y agoNo, this does not mean that the borrow checker understands heap allocations. Box is just a wrapper to shoehorn heap management into the stack based analysis that the borrow checker is able to perform. In other words, Box<> is just the equivalent of std::unique_ptr in C++.
- dthul 7y agoI see what you mean, but I think there are two orthogonal issues here. One is the ownership/lifetime of the heap allocation. That is indeed coupled to a stack object, because non-stack bound lifetimes can (with the current state-of-the-art) not be analyzed at compile time. Calling this shoehorning is strange, that's the whole idea of RAII. The other issue is borrows of heap objects, which the borrow checker can of course handle since they are no different than borrows to stack objects.
- roca 7y agoYes, it's very similar to unique_ptr. The point here is that you can implement many kinds of complex and useful heap-allocated data structures in safe Rust code, without any reference counting, and the compiler will verify that you have no use-after-free bugs, or any other kind of memory-safety bug. The same is not true of (pre-SPARK) Ada, or C, or C++, or BetterC.
- pjmlp 7y agoYou can play around with C++ lifetime analysis in Visual C++ 2019 and clang tidy. It is still WIP, yet to be deployed at large, naturally doesn't cover binary libraries, but it already a very good improvement.
- dthul 7y agoIt's exciting to see C++ pick up some of those ideas! Anything that improves the current situation is appreciated.
- dthul 7y agoSure it does. The borrow checker is concerned about lifetimes, regardless of whether the object lives on the stack or the heap.
- epage 7y agoThe borrow checker is what is being referred to and has no runtime overhead. Now, an environment without a GC will use ref counting sometimes but it will regardless of C, Rust, or C++
- gmueckl 7y agoReference counting has well known issues that are independent of the programming language: - can't deal with circular references without user intervention - storing the reference counter is hard: either it clobbers a whole cache line or it ruins memory alignment - atomic reference counting has the potential to utterly ruin runtime performance unless it used extremely carefully
- steveklabnik 7y agoThe borrow checker does not use reference counting.
- littlestymaar 7y agoI'm pretty sure you are confusing Rust (borrowck, done at compile-time, no runtime overhead) and Swift (where every object is reference-counted, with some, sometimes big, overhead).
- pjmlp 7y agoIn Rust GUI code is quite common to have Rc<RefCell<>> scattered across all widgets callbacks.
- littlestymaar 7y agoI assume you're talking about GTK or Qt? AFAIK they are the only viable options for Rust GUI at the moment, but their paradigm doesn't fit well with Rust ownership and you need to use ref-counting everywhere as you said. I don't think the problem is inherent to GUI in general though.
- ajxs 7y agoSPARK Ada has a concept of pointer ownership that would offer similar protections: https://blog.adacore.com/using-pointers-in-spark https://blog.adacore.com/using-pointers-in-spark
- roca 7y agoThat is true, but SPARK is more heavyweight and less mature than Rust. If someone wants to make the case that SPARK would be a better approach than Rust to writing safe code in the Linux kernel, they should go ahead, but I haven't seen anyone make that case.
- pjmlp 7y agoHow is SPARK less mature than Rust given its use in the industry?
- roca 7y agoI'm talking about SPARK-with-pointers. As of June this year, that was still only available as a preview: > If you now feel like using them, a preview is available in the community 2019 edition of GNAT+SPARK.
- pjmlp 7y agoFair enough, however SPARK-without-pointers is even more constrained in what concerns dynamic allocation, basically it is forbidden and everything must be known at compile time.
- roca 7y agoThis shifting-the-referent bug annoys me, because it happens with C++ too. "C++ is really mature and there are so many C++ projects and developers!" "Yeah but it has these problems..." "Just use C++17, it solves all that!" ... but C++17 is not the language that is really mature and that all those C++ projects and developers are using.
- ajxs 7y ago