Re: [PATCH v2] rust: add safety comment in rust_fmt_argument

[Rasmus Villemoes <ravi@prevas.dk>]

On Mon, Nov 18 2024, Konstantin Andrikopoulos <kernel@mandragore.io> wrote:

> The function rust_fmt_argument dereferences a pointer, and thus it
> needs an unsafe block. The safety comment for that block was missing.
>
>  
> -// Called from `vsprintf` with format specifier `%pA`.
> -#[expect(clippy::missing_safety_doc)]
> +/// Handles the `%pA` format specifier.
> +///
> +/// This function is called by [`vsprintf`] when it encounters a
> `%pA` format specifier in a

Nit: The file implementing this is vsprintf.c, but the actual workhorse
is vsnprintf() (note the n); all other *printf() variants are wrappers
around that, and I'm pretty sure no code path called from Rust ends up
passing through sprintf() or vsprintf(). Yes, I see that the original
code said vsprintf, but please fix while here.

> +/// format string. `ptr` points to the corresponding argument, `buf` points to a buffer to hold
> +/// the formatted argument, and `end` points at the buffer's end.
> +///
> +/// `rust_fmt_argument` treats `ptr` as a pointer to a [`core::fmt::Arguments`], which it formats,
> +/// and writes the result to `buf`.
> +///
> +/// It returns the address after the last byte it has written in `buf`.
> +///
> +/// # Safety
> +///
> +/// `buf` and `end` must follow the requirements of [`RawFormatter`]. `ptr` must be valid for
> +/// reading a [`core::fmt::Arguments`].
> +///
> +/// `vsprintf` guarantees that `buf` and `end` will uphold their
> requirements. However, it will

Same here.

> +/// just forward the argument that corresponds to `%pA`. Callers that provide format strings must
> +/// guarantee that arguments which correspond to `%pA` are valid pointers.
> +///
> +/// [`vsprintf`]: srctree/lib/vsprintf.c

Same here (the filename is correct).

Rasmus