Hi Rasmus, On Tue, Jul 08, 2025 at 08:43:57AM +0200, Rasmus Villemoes wrote: > On Sat, Jul 05 2025, Alejandro Colomar <a...@kernel.org> wrote: > > > On top of that, I have a question about the functions I'm adding, > > and the existing kernel snprintf(3): The standard snprintf(3) > > can fail (return -1), but the kernel one doesn't seem to return <0 ever. > > Should I assume that snprintf(3) doesn't fail here? > > Yes. Just because the standard says it may return an error, as a QoI > thing the kernel's implementation never fails. That also means that we > do not ever do memory allocation or similar in the guts of vsnsprintf > (that would anyway be a mine field of locking bugs).
All of that sounds reasonable. > If we hit some invalid or unsupported format specifier (i.e. a bug in > the caller), we return early, but still report what we wrote until > hitting that. However, there's the early return due to size>INT_MAX || size==0, which results in no string at all, and there's not an error code for this. A user might think that the string is reliable after a vsprintf(3) call, as it returned 0 --as if it had written ""--, but it didn't write anything. I would have returned -EOVERFLOW in that case. I think something similar is true of strscpy(): it returns -E2BIG on size==0 || size>INT_MAX but it should be a different error code, as there's no string at all. I'll propose something very close to strscpy() for standardization, but the behavior for size==0 will either be undefined, or errno will be EOVERFLOW. Have a lovely day! Alex -- <https://www.alejandro-colomar.es/>
signature.asc
Description: PGP signature
