9 ms·

Not 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

Not 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 ago
Corrrections 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 ago
  The answer is basically "stack probes", yes.
  - Someone 10y ago
    I 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 ago
      They're dynamic checks. Static checks for stack overflows are infeasible.
      - Someone 10y ago
        They 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 ago
      They'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 ago
It'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 ago
  Is getting that past the person who is reviewing your code also trivial?
  - sidlls 10y ago
    Possibly. 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 ago
  For 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 ago
    Do you have any idea how impossible it is to do anything useful without unsafe in Rust on a microcontroller?
    - pjmlp 10y ago
      If Ada, Pascal and Basic can, so can Rust. Every case where this is not true is a bug.
milesrout 10y ago
It certainly is possible in Rust. Rust is not memory safe.
- pjmlp 10y ago
  As 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.

Someone 10y ago

Corrrections 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 ago
The answer is basically "stack probes", yes.
- Someone 10y ago
  I 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 ago
    They're dynamic checks. Static checks for stack overflows are infeasible.
    - Someone 10y ago
      They 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 ago
    They'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 ago

It'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 ago
Is getting that past the person who is reviewing your code also trivial?
- sidlls 10y ago
  Possibly. 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 ago
For 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 ago
  Do you have any idea how impossible it is to do anything useful without unsafe in Rust on a microcontroller?
  - pjmlp 10y ago
    If Ada, Pascal and Basic can, so can Rust. Every case where this is not true is a bug.

milesrout 10y ago

It certainly is possible in Rust. Rust is not memory safe.

pjmlp 10y ago
As 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.