Re: [PATCH v4 21/22] 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:
- [Low] rust: str: CString::into_vec() ambiguously retains NUL terminator
--

commit 2eeadc6d96d6cb1bbc75fa7b1a4d782fb1ed8cd5
Author: Alistair Francis <alistair@alistair23.me>
rust: allow extracting the buffer from a CString

This patch introduces a method to consume a CString and retrieve its
underlying buffer. It allows users to convert a string to a CString and
then access the internal KVec directly.

> 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: Low]
This isn't a bug, but could the name of this method cause confusion about
whether the NUL terminator is retained in the returned vector?

In the standard library, std::ffi::CString uses into_bytes() to drop the
terminator and into_bytes_with_nul() to retain it. Because into_vec()
silently retains the trailing NUL byte, could developers assume it drops
it, similar to standard string conversions?

Could this lead to regressions like off-by-one errors or embedded NUL bytes
when the buffer is used for network payloads? Would it be clearer to use a
naming convention that explicitly indicates the presence of the terminator?

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