On Tue, 11 Feb 2025 21:13:10 +0100
Andreas Hindborg <a.hindborg@xxxxxxxxxx> wrote:
> "Gary Guo" <gary@xxxxxxxxxxx> writes:
>
> > On Tue, 11 Feb 2025 16:57:39 +0100
> > Andreas Hindborg <a.hindborg@xxxxxxxxxx> 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@xxxxxxxxxx>
> >> ---
> >> rust/kernel/str.rs | 111 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> 1 file changed, 111 insertions(+)
> >>
> >> diff --git a/rust/kernel/str.rs b/rust/kernel/str.rs
> >> index c102adac32757..192cd0ff5974f 100644
> >> --- a/rust/kernel/str.rs
> >> +++ b/rust/kernel/str.rs
> >> @@ -945,3 +945,114 @@ 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::alloc::flags;
> >> + 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 {
> >> + /// 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', ..] => (16, &src[2..]),
> >
> > This can be written as
> >
> > [b'0', b'x' | b'X', rest @ ..] => (16, rest),
> >
> > to avoid manual indexing. Same for o and b below.
>
> error[E0308]: mismatched types
> --> /home/aeh/src/linux-rust/module-params/rust/kernel/str.rs:972:52
> |
> 972 | [b'0', b'x' | b'X', rest @ ..] => (16, rest),
> | ^^^^ expected `&BStr`, found `&[u8]`
> |
> = note: expected reference `&BStr`
> found reference `&[u8]`
>
> But I guess I could use the new AsRef impl. Or is it more idiomatic to
> implement `From<&[u8]> for &BStr` and go with `rest.into()`?
Ah, alright, I missed that this function is operating on BStr instead
of slice. Keeping the current form is fine then.
>
> >
> >> + [b'0', b'o' | b'O', ..] => (8, &src[2..]),
> >> + [b'0', b'b' | b'B', ..] => (2, &src[2..]),
> >> + [b'0', ..] => (8, src),
> >
> > Perhaps add a comment saying that this isn't using `src[1..]` so `0`
> > can be parsed.
>
> Good idea.
>
> >
> >> + _ => (10, src),
> >> + }
> >> + }
> >> + pub trait ParseInt: FromStrRadix {
> >> + /// Parse a string according to the description in [`Self`].
> >> + fn from_str(src: &BStr) -> Result<Self> {
> >> + match src.iter().next() {
> >> + None => Err(EINVAL),
> >> + Some(sign @ b'-') | Some(sign @ b'+') => {
> >> + let (radix, digits) = strip_radix(BStr::from_bytes(&src[1..]));
> >> + let mut n_digits: KVec<u8> =
> >> + KVec::with_capacity(digits.len() + 1, flags::GFP_KERNEL)?;
> >> + n_digits.push(*sign, flags::GFP_KERNEL)?;
> >> + n_digits.extend_from_slice(digits, flags::GFP_KERNEL)?;
> >
> > I think my comment from a previous series saying that this shouldn't
> > need allocation is not addressed.
>
> Thanks for noticing. This is the discussion from v4:
>
> >> I don't think we should allocate for parsing. This can trivially be a
> >> non-allocating. Just check that the next byte is an ASCII digit (reject
> >> if so, in case people give multiple signs), and then from_str_radix and
> >> return as is or use `checked_neg`.
> >
> >The issue with that approach is that 2s complement signed integer types
> >of width `b` can assume values from -2^(b-1) to (2^(b-1))-1. We would
> >reject the value -2^(b-1) when trying to parse as 2^(b-1).
> >
> >We could parse into an unsigned type, but it gets kind of clunky.
I would say either that or just call into kstrto* family.
Best,
Gary
> >
> >Another option is to stop relying on `from_str_radix` from core and roll
> >our own that takes sign as a separate function argument.
>
> What is your take on that?
>
>
> Best regards,
> Andreas Hindborg
>
>
