[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CANiq72mvu54B=U+YCUmbFctj_wXgF5zjeE-BB-vHVnAP+3mPcQ@mail.gmail.com>
Date: Sun, 4 May 2025 21:41:36 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Antonio Hickey <contact@...oniohickey.com>
Cc: Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>,
Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
Björn Roy Baron <bjorn3_gh@...tonmail.com>,
Benno Lossin <benno.lossin@...ton.me>, Andreas Hindborg <a.hindborg@...nel.org>,
Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>,
Danilo Krummrich <dakr@...nel.org>, linux-kernel@...r.kernel.org,
rust-for-linux@...r.kernel.org
Subject: Re: [PATCH v2 1/1] rust: kernel: create `overflow_assert!`
On Sun, May 4, 2025 at 6:56 PM Antonio Hickey <contact@...oniohickey.com> wrote:
>
> +/// Overflow assert (i.e. runtime bound check).
Probably this paragraph can be removed, since we have the explanation
below, i.e. the first line/title is enough.
> + core::assert!($x <= $y, "overflow assertion failed: {} > {}", $x, $y);
Interesting!
I was thinking of just allowing any expression here. I can see the
value in printing the values, but it makes it a bit harder to remember
the comparison and is less flexible -- I can imagine we will have
other operators being used, or even things that are not tested via an
operator.
Perhaps we could have two macros, one for the "any expression" and
another for the `_le` case, like the normal assert has the `_eq`
version. Though we probably want to see the use cases first before
deciding on particular variants, so I would just go for the general
one first only.
Speaking of use cases -- could you please add a sample second patch
with this macro being used somewhere? e.g. see the linked email in the
issue (it does not necessarily need to be a "real patch" that applies
to existing code, although that would be nice).
Also, please fully qualify the path (`::core`) since we are in a macro.
> +macro_rules! assert_no_overflow {
Shouldn't this be the same name? Does it work?
By the way, would it be possible to have the `cfg` attribute inside
the macro, so that we share the docs and so on? i.e. to make the
conditional compilation as local as possible even here :)
i.e. as it is currently done, we can have mistake like not sharing the
"signature", and the generated docs will not have the actual docs of
the macro if it is disabled.
We could also consider using the `cfg!` macro to force it to be always
valid code -- not sure about whether we want that in all cases though.
The standard library does that, though, so perhaps we should do the
same for consistency. If someone really wants to skip it, they can
always do it on the caller side.
Thanks for the patch!
Cheers,
Miguel
Powered by blists - more mailing lists