Re: [PATCH v3 20/21] rust: allow extracting the buffer from a CString

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The `into_vec` method returns a `KVec<u8>` that includes the NUL terminator, deviating from standard Rust `std::ffi::CString` conventions and failing to indicate this in its name, creating a high risk of subtle logic errors.
--

commit c0d8b032f9c0888c9ca7f0f193ec4c7fb49a4747
Author: Alistair Francis <alistair@alistair23.me>

rust: allow extracting the buffer from a CString

This commit adds an into_vec() method to the kernel's CString type. It
allows callers to consume the CString and extract the underlying KVec
buffer.

> diff --git a/rust/kernel/str.rs b/rust/kernel/str.rs
> index a556788bcc5e9..3fd8a218547f4 100644
> --- a/rust/kernel/str.rs
> +++ b/rust/kernel/str.rs
> @@ -870,6 +870,12 @@ pub fn try_from_fmt(args: fmt::Arguments<'_>) -> Result<Self, Error> {
>          // exist in the buffer.
>          Ok(Self { buf })
>      }
> +
> +    /// Return the internal buffer while consuming the original [`CString`]
> +    #[inline]
> +    pub fn into_vec(self) -> KVec<u8> {
> +        self.buf
> +    }

[Severity: Medium]
Will this return a vector that includes the NUL terminator?

In standard Rust, std::ffi::CString::into_bytes() strips the NUL byte, and
there is a separate into_bytes_with_nul() method to retain it. Because this
method is named into_vec() and the documentation doesn't specify how the
NUL byte is handled, could callers unknowingly process an extra NUL byte
if they assume standard behavior?

Could this lead to a regression with incorrect payload lengths if the array
is passed to external subsystems expecting a standard string length?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260901010347.2614656-1-alistair.francis@wdc.com?part=20