4 ms·

Additionally the panic = "abort" disables stack unwinding, and running destructors when panic occurs, so it's a big change to the semantics of the program. It'

by exDM69 3y ago

Additionally the panic = "abort" disables stack unwinding, and running destructors when panic occurs, so it's a big change to the semantics of the program. It's comparable to C++ land -fno-exceptions (not exactly, but similar).

junon 3y ago
Abort panic strategy is common in firmware and osdev, for anyone wondering if there are other use cases.
flohofwoe 3y ago
IMHO when a piece of code decides to panic it should only happen when execution cannot continue under any circumstances, and in such cases all bets are off whether any cleanup code would actually still work. A hard abort might indeed be the best option.
- edflsafoiewq 3y ago
  That seems overly pessimistic (or perhaps overly optimistic about code that does not panic). Panics mostly exist to guard code from entering into such unrecoverable states, eg writing past the end of an array.
  - flohofwoe 3y ago
    For me the difference would be: if the write past the array has been detected before it happens (via a range check) it would be a regular error which which can be handled, while a panic would be "oops somebody else has written past the end of the array" (e.g. a hitting a canary check), which should abort immediately because at that point it's no longer guaranteed that any recovery code would even work or just make things worse (e.g. trying to flush data from memory back to disk, but that data might have been corrupted too).
    - lifthrasiir 3y ago
      You have a good point and lock poisoning had the same reasoning, but wasn't really popular [1]. (In hindsight the poisoning itself was a great idea but should have been decoupled from locks.) Compared to other languages with similar constructs, Rust panic is probably regarded as less fatal because an incorrect but safe Rust code tends to have a limited reach. Ah, and it should be also noted that some non-fatal signals were also delivered only via panic. The best-known example is a memory allocation failure, which is recoverable in Rust but needed unwinding for a long time. Nowadays you have an unsafe but non-unwinding alternative. [1] https://blog.rust-lang.org/2020/12/11/lock-poisoning-survey.html https://blog.rust-lang.org/2020/12/11/lock-poisoning-survey....
    - edflsafoiewq 3y ago
      In Rust, out of bound array accesses are detected before they happen and handled by panicking.

by exDM69 3y ago

junon 3y ago

Abort panic strategy is common in firmware and osdev, for anyone wondering if there are other use cases.

flohofwoe 3y ago

IMHO when a piece of code decides to panic it should only happen when execution cannot continue under any circumstances, and in such cases all bets are off whether any cleanup code would actually still work. A hard abort might indeed be the best option.

edflsafoiewq 3y ago
That seems overly pessimistic (or perhaps overly optimistic about code that does not panic). Panics mostly exist to guard code from entering into such unrecoverable states, eg writing past the end of an array.
- flohofwoe 3y ago
  For me the difference would be: if the write past the array has been detected before it happens (via a range check) it would be a regular error which which can be handled, while a panic would be "oops somebody else has written past the end of the array" (e.g. a hitting a canary check), which should abort immediately because at that point it's no longer guaranteed that any recovery code would even work or just make things worse (e.g. trying to flush data from memory back to disk, but that data might have been corrupted too).
  - lifthrasiir 3y ago
    You have a good point and lock poisoning had the same reasoning, but wasn't really popular [1]. (In hindsight the poisoning itself was a great idea but should have been decoupled from locks.) Compared to other languages with similar constructs, Rust panic is probably regarded as less fatal because an incorrect but safe Rust code tends to have a limited reach. Ah, and it should be also noted that some non-fatal signals were also delivered only via panic. The best-known example is a memory allocation failure, which is recoverable in Rust but needed unwinding for a long time. Nowadays you have an unsafe but non-unwinding alternative. [1] https://blog.rust-lang.org/2020/12/11/lock-poisoning-survey.html https://blog.rust-lang.org/2020/12/11/lock-poisoning-survey....
  - edflsafoiewq 3y ago
    In Rust, out of bound array accesses are detected before they happen and handled by panicking.