5 ms·

No, Rust arrays are not safe by default: https://is.gd/iY5lPQ https://is.gd/iY5lPQ

by EugeneOZ 10y ago

steveklabnik 10y ago
Panics are definitely safe. They are significantly different than the segfault you'd get out of the C code.
- EugeneOZ 10y ago
  Besides of memory safety, what is different in panicking? I'm not trying to argue - I don't know it. For me result is the same - process failed. What is difference in consequences for memory?
  - gue5t 10y ago
    Not all violations of memory safety result in immediate program termination. There's an intervening period of execution during which your program simply performs unintended operations such as overwriting unrelated memory (which could be a memory-mapped file), terminating "correctly" (and performing whatever operations that entails) with corrupt state, and generally an unbounded set of other potential consequences. An immediate segfault is the absolute best hope for a program without memory safety, since you both see no unintended effects performed on the program's behalf and you learn that your program needs fixing.
    - EugeneOZ 10y ago
      Got it, thank you.
  - gpderetta 10y ago
    Panic behaviour is well defined. Segfaults are non-reliable (i.e. it might or might not crash) and often exploitable.
- ue_ 10y ago
  There are tools you can use with C compilers that don't access OOB memory on OOB access. What's your point? I think I'd rather not have it panic at all. They were making a language from scratch and still didn't solve the crash-at-runtime problem that C has. Instead they just made a common C compiler option default and called it 'safe'. It's worse than the fact that the Go creators ignored years of research after the year 1970 and didn't implement generics, for no good reason. Rust's safety is a joke, and so is the idea that a lot of it is anything 'new'. They had the chance to fix it and they didn't. Boo.
  - steveklabnik 10y ago
    > What's your point? My point is that panics are memory safe, contrary to what my parent said.
  - the_why_of_y 10y ago
    Which common C compiler has a production quality implementation of array bounds checking? Before you say Address Sanitizer you should be aware that its authors intended it as a debugging tool and recommend against using it in production as it introduces new attack surface, as described in the "Address Sanitizer local root" mail. http://seclists.org/oss-sec/2016/q1/363 http://seclists.org/oss-sec/2016/q1/363
staticassertion 10y ago
Panics do not violate memory safety. In C that code would be undefined behavior.
- EugeneOZ 10y ago
  You are right, my mistake. I just can't call code failing in runtime "safe" (because I can't rely on it). But in terms of memory safety it's safe.
  - moosingin3space 10y ago
    Then use the get() function on an array/slice. It returns an Option so it won't perform an access off the end of the array, and you can catch it.
    - EugeneOZ 10y ago
      thanks, I do. Only thing left is explain it to everybody else to avoid panicking in 3-party crates. I really hate when people use panicking just because it's easier than error handling. So it was "surprise" to see such behavior from "[x]" construction.
      - cesarb 10y ago
        Like in C, you are not supposed to pass out-of-bounds indexes to the [] operator. If anyone does so, it's a bug. Rust converts it to a panic, which safely terminates the thread/program, instead of C's undefined behavior. You can also catch this panic at the thread boundary, so other threads in your program can keep running, unless the program was compiled to call abort() on panic.
        EugeneOZ 10y ago
        You still think in C limits of possibilities. Rust could just return Option as a result for [x] syntax.
outworlder 10y ago
I get: thread 'main' panicked at 'index out of bounds: the len is 3 but the index is 4' Looks pretty safe to me.
- ue_ 10y ago
  How is such a crash remotely safe, for example, in an aviation system? Or a hospital's main computer? A panic isn't safe, and if you are going to claim that it is, you can get the same safety in C using gcc and clang features.
  - cesarb 10y ago
    > A panic isn't safe, and if you are going to claim that it is, you can get the same safety in C using gcc and clang features. There's one important difference. As far as I know, the bounds checking of gcc or clang can either print a warning and continue, or terminate the process. A panic in Rust, however, will safely unwind the stack (similar to a C++ exception, in fact it's the same mechanism) and terminate only the thread. The rest of the program can continue running, and even start a new thread to replace the terminated one. You can see this in action when running "cargo test". A panic in a test (the assert!() and assert_eq!() macros, often used in tests, do a panic in case of failure) will not terminate the whole process; the rest of the tests still run.
    - steveklabnik 10y ago
      (panics are for "non-recoverable" errors, and so don't _have_ to unwind the stack: you can abort on panic as well. The important difference is that you get well-defined behavior in all cases.)
    - macintux 10y ago
      This sounds like the "fail fast" philosophy in Erlang. Crashing is the standard behavior for any unexpected data, but the process model makes it straightforward to manage those crashes.
  - dbaupp 10y ago

No, Rust arrays are not safe by default: https://is.gd/iY5lPQ https://is.gd/iY5lPQ

steveklabnik 10y ago

Panics are definitely safe. They are significantly different than the segfault you'd get out of the C code.

EugeneOZ 10y ago
Besides of memory safety, what is different in panicking? I'm not trying to argue - I don't know it. For me result is the same - process failed. What is difference in consequences for memory?
- gue5t 10y ago
  Not all violations of memory safety result in immediate program termination. There's an intervening period of execution during which your program simply performs unintended operations such as overwriting unrelated memory (which could be a memory-mapped file), terminating "correctly" (and performing whatever operations that entails) with corrupt state, and generally an unbounded set of other potential consequences. An immediate segfault is the absolute best hope for a program without memory safety, since you both see no unintended effects performed on the program's behalf and you learn that your program needs fixing.
  - EugeneOZ 10y ago
    Got it, thank you.
- gpderetta 10y ago
  Panic behaviour is well defined. Segfaults are non-reliable (i.e. it might or might not crash) and often exploitable.
ue_ 10y ago
There are tools you can use with C compilers that don't access OOB memory on OOB access. What's your point? I think I'd rather not have it panic at all. They were making a language from scratch and still didn't solve the crash-at-runtime problem that C has. Instead they just made a common C compiler option default and called it 'safe'. It's worse than the fact that the Go creators ignored years of research after the year 1970 and didn't implement generics, for no good reason. Rust's safety is a joke, and so is the idea that a lot of it is anything 'new'. They had the chance to fix it and they didn't. Boo.
- steveklabnik 10y ago
  > What's your point? My point is that panics are memory safe, contrary to what my parent said.
- the_why_of_y 10y ago
  Which common C compiler has a production quality implementation of array bounds checking? Before you say Address Sanitizer you should be aware that its authors intended it as a debugging tool and recommend against using it in production as it introduces new attack surface, as described in the "Address Sanitizer local root" mail. http://seclists.org/oss-sec/2016/q1/363 http://seclists.org/oss-sec/2016/q1/363

staticassertion 10y ago

Panics do not violate memory safety. In C that code would be undefined behavior.

EugeneOZ 10y ago
You are right, my mistake. I just can't call code failing in runtime "safe" (because I can't rely on it). But in terms of memory safety it's safe.
- moosingin3space 10y ago
  Then use the get() function on an array/slice. It returns an Option so it won't perform an access off the end of the array, and you can catch it.
  - EugeneOZ 10y ago
    thanks, I do. Only thing left is explain it to everybody else to avoid panicking in 3-party crates. I really hate when people use panicking just because it's easier than error handling. So it was "surprise" to see such behavior from "[x]" construction.
    - cesarb 10y ago
      Like in C, you are not supposed to pass out-of-bounds indexes to the [] operator. If anyone does so, it's a bug. Rust converts it to a panic, which safely terminates the thread/program, instead of C's undefined behavior. You can also catch this panic at the thread boundary, so other threads in your program can keep running, unless the program was compiled to call abort() on panic.
      - EugeneOZ 10y ago
        You still think in C limits of possibilities. Rust could just return Option as a result for [x] syntax.

outworlder 10y ago

I get: thread 'main' panicked at 'index out of bounds: the len is 3 but the index is 4' Looks pretty safe to me.

ue_ 10y ago
How is such a crash remotely safe, for example, in an aviation system? Or a hospital's main computer? A panic isn't safe, and if you are going to claim that it is, you can get the same safety in C using gcc and clang features.
- cesarb 10y ago
  > A panic isn't safe, and if you are going to claim that it is, you can get the same safety in C using gcc and clang features. There's one important difference. As far as I know, the bounds checking of gcc or clang can either print a warning and continue, or terminate the process. A panic in Rust, however, will safely unwind the stack (similar to a C++ exception, in fact it's the same mechanism) and terminate only the thread. The rest of the program can continue running, and even start a new thread to replace the terminated one. You can see this in action when running "cargo test". A panic in a test (the assert!() and assert_eq!() macros, often used in tests, do a panic in case of failure) will not terminate the whole process; the rest of the tests still run.
  - steveklabnik 10y ago
    (panics are for "non-recoverable" errors, and so don't _have_ to unwind the stack: you can abort on panic as well. The important difference is that you get well-defined behavior in all cases.)
  - macintux 10y ago
    This sounds like the "fail fast" philosophy in Erlang. Crashing is the standard behavior for any unexpected data, but the process model makes it straightforward to manage those crashes.
- dbaupp 10y ago