Many of their TOCTOU issues are something a type system can help with. Require operations to execute on a fd handle directly rather than using convenience functions.
let fd = FileDescriptor::new(path);
fd.delete()?;
fd.create(mode)?;
let is_root = fd == FileDescriptor::new("/"); // does (dev, inode) comparison internally
// etc
The uutils devs would need to create that themselves, but OpenOptions seems to get them part of the way there at least.
It’s only enforced because of Rust’s strict type system. Python, on the other hand, lets you do whatever you want by comparison, and complains only at runtime. I’ve seen far too many **kwargs for my liking.
And FD types (e.g. OwnedFd, BorrowedFd) are already in std.
My example would be a thin wrapper around these, most likely. It’s only an example of what I’m trying to convey, though.
I thought one of the goals of Java and similar was partial memory safety? If it didn’t have null it seems it would be most of the way there.
And don’t forget Basic. Yeah most variants had pointers and equivalents to null, but they are ‘advanced’ and not meant for general code. (Although that’s interpreted and you said compiled, often it could be ‘complied’ similarly to Java bytecode)
A null does not make it memory unsafe. You aren’t accessing invalid memory, the runtime just raises a NRE. Which is fine. No memory safety violated.
Java is, as long as you stick to pure java and not native interop, entirely memory safe. And that’s achieved by giving up control of memory allocation to the garbage collector.
Rust is not the first memory safe language. It does however, manage to achieve memory safety without needing a garbage collector. Which is what drew my initial interest.
We said the same about memory safety: That’s something a compiler can not solve. Now it does.
It is nice to see that sometines things do improve.
Memory safety is something compiler understands and has under control, this stuff it does not. Nor it should.
Many of their TOCTOU issues are something a type system can help with. Require operations to execute on a fd handle directly rather than using convenience functions.
The uutils devs would need to create that themselves, but
OpenOptionsseems to get them part of the way there at least.That’s a question of API, not type system. And FD types (e.g.
OwnedFd,BorrowedFd) are already in std.It’s only enforced because of Rust’s strict type system. Python, on the other hand, lets you do whatever you want by comparison, and complains only at runtime. I’ve seen far too many
**kwargsfor my liking.My example would be a thin wrapper around these, most likely. It’s only an example of what I’m trying to convey, though.
I thought one of the goals of Java and similar was partial memory safety? If it didn’t have null it seems it would be most of the way there.
And don’t forget Basic. Yeah most variants had pointers and equivalents to null, but they are ‘advanced’ and not meant for general code. (Although that’s interpreted and you said compiled, often it could be ‘complied’ similarly to Java bytecode)
Java and similar (i.e. c#) are memory safe and run on garbage collected runtime.
A null does not make it memory unsafe. You aren’t accessing invalid memory, the runtime just raises a NRE. Which is fine. No memory safety violated.
Java is, as long as you stick to pure java and not native interop, entirely memory safe. And that’s achieved by giving up control of memory allocation to the garbage collector.
Rust is not the first memory safe language. It does however, manage to achieve memory safety without needing a garbage collector. Which is what drew my initial interest.