[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <24221C62-2470-4B03-B39B-58BCDC500D68@collabora.com>
Date: Mon, 24 Feb 2025 10:34:11 -0300
From: Daniel Almeida <daniel.almeida@...labora.com>
To: Andreas Hindborg <a.hindborg@...nel.org>
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>,
Alice Ryhl <aliceryhl@...gle.com>,
Trevor Gross <tmgross@...ch.edu>,
Masahiro Yamada <masahiroy@...nel.org>,
Nathan Chancellor <nathan@...nel.org>,
Nicolas Schier <nicolas@...sle.eu>,
Luis Chamberlain <mcgrof@...nel.org>,
rust-for-linux@...r.kernel.org,
linux-kernel@...r.kernel.org,
Adam Bratschi-Kaye <ark.email@...il.com>,
linux-kbuild@...r.kernel.org,
Petr Pavlu <petr.pavlu@...e.com>,
Sami Tolvanen <samitolvanen@...gle.com>,
Daniel Gomez <da.gomez@...sung.com>,
Simona Vetter <simona.vetter@...ll.ch>,
Greg KH <gregkh@...uxfoundation.org>,
linux-modules@...r.kernel.org
Subject: Re: [PATCH v7 5/6] rust: str: add radix prefixed integer parsing
functions
Hi Andreas,
> On 18 Feb 2025, at 10:00, Andreas Hindborg <a.hindborg@...nel.org> wrote:
>
> Add the trait `ParseInt` for parsing string representations of integers
> where the string representations are optionally prefixed by a radix
> specifier. Implement the trait for the primitive integer types.
>
> Signed-off-by: Andreas Hindborg <a.hindborg@...nel.org>
> ---
> rust/kernel/str.rs | 118 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 118 insertions(+)
>
> diff --git a/rust/kernel/str.rs b/rust/kernel/str.rs
> index db272d2198fcc..8b0d814b47f52 100644
> --- a/rust/kernel/str.rs
> +++ b/rust/kernel/str.rs
> @@ -945,3 +945,121 @@ fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
> macro_rules! fmt {
> ($($f:tt)*) => ( core::format_args!($($f)*) )
> }
> +
> +pub mod parse_int {
> + //! Integer parsing functions for parsing signed and unsigned integers
> + //! potentially prefixed with `0x`, `0o`, or `0b`.
> +
> + use crate::prelude::*;
> + use crate::str::BStr;
> + use core::ops::Deref;
> +
> + /// Trait that allows parsing a [`&BStr`] to an integer with a radix.
> + ///
> + /// [`&BStr`]: kernel::str::BStr
> + // This is required because the `from_str_radix` function on the primitive
> + // integer types is not part of any trait.
> + pub trait FromStrRadix: Sized {
Is this supposed to be implemented by somebody else? Otherwise we should seal it,
perhaps?
> + /// Parse `src` to `Self` using radix `radix`.
> + fn from_str_radix(src: &BStr, radix: u32) -> Result<Self, crate::error::Error>;
> + }
> +
> + /// Extract the radix from an integer literal optionally prefixed with
> + /// one of `0x`, `0X`, `0o`, `0O`, `0b`, `0B`, `0`.
> + fn strip_radix(src: &BStr) -> (u32, &BStr) {
> + match src.deref() {
> + [b'0', b'x' | b'X', rest @ ..] => (16, rest.as_ref()),
> + [b'0', b'o' | b'O', rest @ ..] => (8, rest.as_ref()),
> + [b'0', b'b' | b'B', rest @ ..] => (2, rest.as_ref()),
> + // NOTE: We are including the leading zero to be able to parse
> + // literal 0 here. If we removed it as a radix prefix, we would not
> + // be able to parse `0`.
> + [b'0', ..] => (8, src),
> + _ => (10, src),
> + }
> + }
> +
> + /// Trait for parsing string representations of integers.
> + ///
> + /// Strings beginning with `0x`, `0o`, or `0b` are parsed as hex, octal, or
> + /// binary respectively. Strings beginning with `0` otherwise are parsed as
> + /// octal. Anything else is parsed as decimal. A leading `+` or `-` is also
> + /// permitted. Any string parsed by [`kstrtol()`] or [`kstrtoul()`] will be
> + /// successfully parsed.
> + ///
> + /// [`kstrtol()`]: https://www.kernel.org/doc/html/latest/core-api/kernel-api.html#c.kstrtol
> + /// [`kstrtoul()`]: https://www.kernel.org/doc/html/latest/core-api/kernel-api.html#c.kstrtoul
> + ///
> + /// # Example
> + /// ```
> + /// use kernel::str::parse_int::ParseInt;
> + /// use kernel::b_str;
> + ///
> + /// assert_eq!(Ok(0), u8::from_str(b_str!("0")));
> + ///
> + /// assert_eq!(Ok(0xa2u8), u8::from_str(b_str!("0xa2")));
> + /// assert_eq!(Ok(-0xa2i32), i32::from_str(b_str!("-0xa2")));
> + ///
> + /// assert_eq!(Ok(-0o57i8), i8::from_str(b_str!("-0o57")));
> + /// assert_eq!(Ok(0o57i8), i8::from_str(b_str!("057")));
> + ///
> + /// assert_eq!(Ok(0b1001i16), i16::from_str(b_str!("0b1001")));
> + /// assert_eq!(Ok(-0b1001i16), i16::from_str(b_str!("-0b1001")));
> + ///
> + /// assert_eq!(Ok(127), i8::from_str(b_str!("127")));
> + /// assert!(i8::from_str(b_str!("128")).is_err());
> + /// assert_eq!(Ok(-128), i8::from_str(b_str!("-128")));
> + /// assert!(i8::from_str(b_str!("-129")).is_err());
> + /// assert_eq!(Ok(255), u8::from_str(b_str!("255")));
> + /// assert!(u8::from_str(b_str!("256")).is_err());
> + /// ```
^ These are passing
> + pub trait ParseInt: FromStrRadix + TryFrom<i128> {
Should this be sealed too?
> + /// Parse a string according to the description in [`Self`].
> + fn from_str(src: &BStr) -> Result<Self> {
> + match src.deref() {
> + [b'-', rest @ ..] => {
> + let (radix, digits) = strip_radix(rest.as_ref());
> + // 2's complement values range from -2^(b-1) to 2^(b-1)-1.
> + // So if we want to parse negative numbers as positive and
> + // later multiply by -1, we have to parse into a larger
> + // integer. We choose i128 as sufficiently large.
> + let val = i128::from_str_radix(
> + core::str::from_utf8(digits).map_err(|_| EINVAL)?,
> + radix,
> + )
> + .map_err(|_| EINVAL)?;
> + let val = -val;
> + val.try_into().map_err(|_| EINVAL)
> + }
> + _ => {
> + let (radix, digits) = strip_radix(src);
> + Self::from_str_radix(digits, radix).map_err(|_| EINVAL)
> + }
> + }
> + }
> + }
> +
> + macro_rules! impl_parse_int {
> + ($ty:ty) => {
> + impl FromStrRadix for $ty {
> + fn from_str_radix(src: &BStr, radix: u32) -> Result<Self, crate::error::Error> {
> + <$ty>::from_str_radix(core::str::from_utf8(src).map_err(|_| EINVAL)?, radix)
> + .map_err(|_| EINVAL)
> + }
> + }
> +
> + impl ParseInt for $ty {}
> + };
> + }
> +
> + impl_parse_int!(i8);
> + impl_parse_int!(u8);
> + impl_parse_int!(i16);
> + impl_parse_int!(u16);
> + impl_parse_int!(i32);
> + impl_parse_int!(u32);
> + impl_parse_int!(i64);
> + impl_parse_int!(u64);
> + impl_parse_int!(isize);
> + impl_parse_int!(usize);
> +}
>
> --
> 2.47.0
>
>
>
This overall LGTM. See my comment on whether we should seal the traits.
Powered by blists - more mailing lists