On Wed, Aug 27, 2025 at 10:47 AM Alexandre Courbot <acour...@nvidia.com> wrote:
>
> However, `fw_start + fw_size` can panic in debug configuration if it
> overflows. In a release build I believe it will just happily wrap, and
In the kernel, it is a panic in the default configuration, not just a debug one.
We have debug assertions too -- and those are disabled by default, but
they are separate from the overflow checking, which is the one enabled
by default.
So, any use of those operators is limited to cases where one knows,
somehow, that it will not overflow. And e.g. user-controlled inputs
cannot use them at all.
So, conceptually, something like this:
- Static assert if the compiler knows it cannot fail.
- Build assert if the optimizer knows it cannot fail.
- Unfallible (like the possibly panicking operators) if the
developer knows it cannot fail.
- Fallible/wrapping/saturating/... if the developer isn't sure or it
simply cannot be known until runtime. User-derived inputs must use
this option (or rarely the unsafe one).
- Unsafe if the developer knows it cannot fail and the other options
are not acceptable for some reason. Ideally paired with a debug
assertion (the compiler adds these already for many unsafe
preconditions).
In the past I requested upstream Rust a way to have a "third mode"
("report and continue") for the operators so that it would wrap (like
the non-panicking mode) but allowing us to add a customization point
so that we can e.g. `WARN_ON_ONCE`.
That would be ideal, because it is a nice middle ground that is not as
punishing if a developer gets it wrong, especially for "normal users",
where panics typically mean lost reports etc. And other kernel users,
like cloud operators, can keep the panicking mode.
As for discussing no-panic, sure!
Cheers,
Miguel
