5 ms·
You don't get advantages over perfectly written C, but that doesn't exist. Over mortal written C, you gain safety against data races, use after free, and a coup
by foota 10y ago
You don't get advantages over perfectly written C, but that doesn't exist. Over mortal written C, you gain safety against data races, use after free, and a couple other classes of errors. And without needing manual memory management, and with high level ergonomics.
- milesrout 10y agoThe idea that C code is always poorly written is both wrong and offensive.
- vertex-four 10y agoNot poorly written, just it's very easy to forget things, and even very well-written, readable, documented C code usually has memory-related bugs, as long as it's written by fallible humans. Nearly every networked C program in existence has had a buffer overflow CVE at some point - that's simply not possible in Rust.
- Someone 10y agoCorrrections welcome, but I think there is one buffer that you can overflow in every Rust program: the stack. If you have a MMU, the runtime will/should protect against that by mapping a page as 'trap on write' and panicking/rebooting/signaling if you do, but if you don't, I don't think rust has any functionality to prevent it. Or can you declare that your stack is x bytes, and have the compiler verify that no call chain will need more? (That typically would prevent the use of recursion, but that's not too bad)
- steveklabnik 10y agoThe answer is basically "stack probes", yes.
- Someone 10y agoI find very few relevant hits on that on Google (stack probes apparently also are hardware to measure various quantities such as moisture in stacks of materials), and none that explain to me what they are (you can enable them in gcc and Microsoft's compilers, and rust should use them instead of stack overflow checks, but that's about it), but from what I guesstimate, they are runtime instrumentation, not anything that a rust compiler could do to guarantee that a compiled and linked program never overflows the stack. Can you tell me more about them?
- pcwalton 10y agoThey're dynamic checks. Static checks for stack overflows are infeasible.
- Someone 10y agoThey are not infeasible, if you are willing to limit what your language can do. Doing so doesn’t remove all useful programs, as the first Fortran compilers showed (they used a fixed addresses for all variables, be they local or global (that they did not support recursion is not that surprising, given that many CPUs of the time didn’t have a return stack)) That’s why I asked whether Rust supported such a thing. It would be very helpful, for example, if your build system would tell you that that difficult to test error handler would, if called, overflow the stack before you spent time and, possibly, lots of money, on trying to run it.
- steveklabnik 10y agoThey're runtime checks, but they're inserted by the compiler at compile time. So yeah, if you link in code that wasn't compiled with them, then that code isn't protected. You're right that a summary seems hard to find; http://www.delorie.com/gnu/docs/gcc/gccint_124.html http://www.delorie.com/gnu/docs/gcc/gccint_124.html has some decent stuff in it, but given that it's random GCC docs, the details may not be 100% accurate today, I dunno, I'm on a flight layover right now, so that's all I've got at the moment :)
- pcwalton 10y ago> That typically would prevent the use of recursion, but that's not too bad It also prevents the use of indirect calls/virtual functions, because they can hide recursion. That's Bad.
- sidlls 10y agoIt's fairly trivial to overflow a buffer in Rust. I don't consider having to write "unsafe { /* overflow buffer code goes here */}" non-trivial.
- jononor 10y agoIs getting that past the person who is reviewing your code also trivial?
- sidlls 10y agoPossibly. Depends on the quality of the reviewer and the complexity of the code (as a whole). On average Rust programmers aren't necessarily better than programmers using any other language. If history is a guide then if Rust takes off there will be plenty of terrible, buggy, unsafe and very thoroughly reviewed Rust code out there used in popular, widely used applications or services. I find the notion that "explicit unsafe makes bugs less likely" to be suspect. It seems reasonable, almost tautological at first glance. But theory and practice are different animals.
- jononor 10y agoFor embedded code, I'd recommend that all application code should be compiled with the `--deny unsafe-code` option. Then the compiler will stop you. A separate module for the I/O code providing is the only place where one should use `unsafe`. Extra care must be taken here, in code review and in testing.
- milesrout 10y agoIt certainly is possible in Rust. Rust is not memory safe.
- pjmlp 10y agoAs it is in any language that has FFI to Assembly. But that is a big difference in the amount of unsafety per line of code.
- unrealhoang 10y agoIMHO There's a big gap between perfectly written and poorly written
- jononor 10y agoMost code is less-than-perfect, independently of language. But the consequences of this depends on the language.
- staticassertion 10y agoNot really. We can simply expand it to "All code has bugs", and then we're simply at Rice's theorem. In C, the class of bugs that can not be proven to not exist are also quite dangerous - remote code execution, as an exemplar consequence. In rust, you're limited to a program that can crash, or that has other semantic faults. So it's clearly not wrong, and is actually a totally well established idea well outside of the context of rust or C.
- Thrillington 10y agoAn 8-bit AVR executes instructions from on board flash memory that requires twiddling hardware lines to erase and rewrite. Remote code execution isn't a concern.
- pjmlp 10y agoNo, but memory corruption related to pointers misuse or unsigned arithmetic is.
- boznz 10y agoAVR ATMega is self programmable ie a bootloader can re-flash it if its configured to allow but you would need some code already resident on the flash to allow, it couldnt be done without this code.
- milesrout 10y agoYou can very easily have all the sorts of memory unsafety you have in C, in Rust.