4

Recently I was writing a driver for a pressure sensor and was avoiding using floating-point instructions as the microcontroller I am using doesn't have a hardware FPU and emulated instructions are rather expensive. I made an error in the type I used to store the result of the multiplication. As a result with some inputs, this code would overflow the integer and panic.

This is great, as it meant that I found the bug before it got out into production. But on further research, it seems that this integer-overflow check is only enabled on debug builds and is later disabled on release builds.

So in an attempt to find all the cases where panic would occur in my code I created a fuzzing framework specifically for hardware drivers which can be found here. This framework could find and backtrace the bug and I later found a few others in other driver code. So that's great, but I can't be 100% sure that the fuzzing engine has found all the ways that my driver could panic.

Based on the research that I've done here are all the ways that rust will panic;

  1. An explicit call to panic! (I can mitigate this with a code-review of my deps).
  2. An explicit call to unwrap (I can mitigate this with a code-review of my deps).
  3. Indexing an array out of bounds.
  4. Overflowing an integer (In debug mode only)
  5. Dividing by 0

Before finding the bug described above I was only aware of cases 1,2,4 as potential areas where rust would panic, as they were the cases that seem to be the most touted/documented features of rust.

Are there any other cases where core rust (i.e. nostd), will panic?

As a follow-up question; is there any way to be 100% sure that there is no possible code pathway that my code could ever panic e.g. via static analysis or another method?

silvergasp
  • 1,517
  • 12
  • 23

2 Answers2

3

There are many functions in core that panic when used improperly (random example: AtomicI64::load). All of these panics are documented in the core documentation. There are also ways that panics can occur even without an explicit function call or macro invocation in core. All of these are syntax sugar for a core trait (such as Add or Index) but are typically invoked using their syntax sugar, and are implemented with compiler magic (code generation is handled differently than normal by the compiler):

  • +/-/*/>>/<< panic on overflow in debug mode
  • dividing by zero or modulusing zero (x / 0 or x % 0)
  • for signed integer types, i*::MIN / -1 and i*::MIN % -1 always panics, even in release mode
  • for signed integer types, -i*::MIN
  • performing an out of bounds array index into a slice/array/str

The no_panic crate can be used to statically verify that a function will never panic. There are a few catches to be aware of when using this crate — be sure to read the documentation first.

smitop
  • 4,770
  • 2
  • 20
  • 53
  • shouldn't be this part of the standard library, it is really shady behavior. – Daniel Jun 21 '22 at 19:08
  • @Daniel: Shouldn't *what* be part of the standard library? `no_panic`? Or something else? And what's shady about any of this? – ShadowRanger Jun 21 '22 at 19:08
  • "There are also ways that panics can occur even without a function call or macro invocation in core", what is this about? – Daniel Jun 21 '22 at 19:11
  • @Daniel: That's what the next sentence and the list is describing; implicit invocation of traits used for operator overloading. The code the human sees is `x + y` (no `.name()` function call or macro invocation visible), but the implementation is `x`'s implementation of `add` for the `Add` trait. The list is describing the cases where this happens (not sure if the list is intended to be exhaustive). I don't think it's unreasonable to allow panics for doc'd cases like this (benefit of Rust is not allowing errors to pass silently; ideally caught at compile time, but that's not always possiblt). – ShadowRanger Jun 21 '22 at 19:15
  • this answer is incomplete, "compiler magic" makes no sense , there are always function or macros called, no matter the top syntax. "without a function call or macro invocation in core" makes no sense. – Daniel Jun 21 '22 at 19:19
  • @Daniel: I clarified it a bit – smitop Jun 21 '22 at 19:22
  • Thanks for your explanation, I hadn't even considered operator overloads. the no_panic crate seems like it should suit my needs! – silvergasp Jun 21 '22 at 19:39
2

This crate could help you. It statically checks that no panics remain in the compiled program https://crates.io/crates/no-panics-whatsoever.

AlexN
  • 1,613
  • 8
  • 21