Re: [PATCH 0/2] rust: str: parse_int: match kstrtol() sign and newline handling
From: Miguel Ojeda
Date: Wed Oct 28 2026 - 09:04:16 EST
On Tue, Oct 27, 2026 at 1:10 PM Younes Akhouayri via B4 Relay
<devnull+git.younes.io@xxxxxxxxxx> wrote:
>
> The documentation of `ParseInt` says that any string parsed by
> `kstrtol()` or `kstrtoul()` is also parsed by `from_str()`. That does
> not hold today, and `from_str()` also accepts strings that `kstrtol()`
> rejects:
>
> input kstrtoint() i32::from_str()
> "0x-5" -EINVAL Ok(-5)
> "0x+5" -EINVAL Ok(5)
> "-+5" -EINVAL Ok(-5)
> "+0x5" 5 Err(EINVAL)
> "5\n" 5 Err(EINVAL)
I think these are indeed fixes in that the docs do not match the code,
though it seems nobody depends on this except the sample, so probably
they will go in rust-next.
Not sure about backporting -- I guess in principle an external module
could be relying on the old behavior by chance, while nobody needs the
new one in-tree.
By the way, should we add:
assert!(i32::from_str(b_str!("-0x+5")).is_err());
to the first patch for completeness?
Also, in the commit message examples, you mention `kstrtoint()` (also
above), but since the docs talk about specifically about `kstrtol()`
and `kstrtoul()`, maybe it is best to refer to them directly. Not a
big deal, though.
Finally, that:
/// Returns [`EINVAL`] if the digits start with a sign, which
/// `from_str_radix()` would otherwise accept.
could mention which `from_str_radix()` it is talking about and why
(e.g. "so that the result can be passed to ...").
Thanks!
Cheers,
Miguel