4 ms·
> C allows the developer to play fast and loose with the rules. So does Rust, in unsafe blocks. Is there anything that can be done in C that can’t be done in u
by School-Cotton 5y ago
> C allows the developer to play fast and loose with the rules.
So does Rust, in unsafe blocks. Is there anything that can be done in C that can’t be done in unsafe Rust?
- vvanders 5y agoOnly thing that comes to mind immediately is VLA/alloca but I'd have to check. Most of the gnarly pointer things are fair game and work just as well as their C counterparts.
- bbatha 5y agoRust supports VLAs, Box<[T]> is pretty common in fact. It just doesn’t have a native way to alloc them on the stack.
- pjmlp 5y agoVLA are thankfully no longer required for ISO C compliance, who had thought it was a good idea in first place? Google even sponsored the work to clean the Linux kernel from them.
- cesarb 5y ago> Is there anything that can be done in C that can’t be done in unsafe Rust? Duff's device <https://en.wikipedia.org/wiki/Duff's_device https://en.wikipedia.org/wiki/Duff's_device>.
- josephcsible 5y agoYou're mixing up a thing you can do with a way that you can do something. You can write Rust code with the same observable behavior as Duff's device in C.
- kaba0 5y agoAlso, Duff’s device is pretty terrible and a modern compiler will output much better code.
- LAC-Tech 5y ago> You're mixing up a thing you can do with a way that you can do something. I don't think they are. > You can write Rust code with the same observable behavior as Duff's device in C. Yes, turing complete languages can do that.
- pjmlp 5y agoA good example of cool tricks to impress fellow hackers that have no place in code bases that should meet certain quality levels of long term maintenance.
- saghm 5y agoThere are some architectures that C supports better than Rust due to having gcc's backends as an option as well as LLVM, but within a given architecture that both support, I don't think there is.
- rthomas6 5y agoModifying memory on the heap in multiple threads without a mutex, from one pointer. Why anyone would want that on purpose, I don't know.
- School-Cotton 5y agoWhat stops you from doing this in Rust?
- the_duke 5y agoThe language itself, unless you go out of your way to circumvent the protections with `unsafe`. In this particular case it's the `Sync` trait and the generell rules around sharing data.
- School-Cotton 5y ago> unless you go out of your way to circumvent the protections with `unsafe` I was specifically referring to the things you can do in `unsafe` blocks.
- rthomas6 5y agoIt was my impression that you can't do it even in unsafe because ownership rules still apply. But apparently I was wrong and there is a way to do it?
- School-Cotton 5y agoOwnership rules still apply _to references_, but not to raw pointers. This program prints "12". The only difficulty is that Rust's designers have intentionally made this pattern difficult by marking raw pointers as !Send, but you can get around that by wrapping them in a Send type. use std::{time::Duration, ops::{DerefMut, Deref}}; struct SendWrapper<T>(*mut T); impl<T> Deref for SendWrapper<T> { type Target = T; fn deref(&self) -> &Self::Target { unsafe { self.0.as_ref() }.unwrap() } } impl<T> DerefMut for SendWrapper<T> { fn deref_mut(&mut self) -> &mut Self::Target { unsafe { self.0.as_mut() }.unwrap() } } unsafe impl<T> Send for SendWrapper<T> {} fn main() { let mut x = 10; let p1: *mut usize = &mut x; let p2: *mut usize = &mut x; let mut s1 = SendWrapper(p1); let mut s2 = SendWrapper(p2); let j1 = std::thread::spawn(move || { *s1.deref_mut() += 1; }); let j2 = std::thread::spawn(move || { std::thread::sleep(Duration::from_secs(1)); *s2.deref_mut() += 1; }); j1.join().unwrap(); j2.join().unwrap(); println!("x: {}", x); }