Hi Rasmus, On Tue, Jul 08, 2025 at 03:51:10PM +0200, Rasmus Villemoes wrote: > > However, there's the early return due to size>INT_MAX || size==0, > > which > > First of all, there's no early return for size==0, that's absolutely > supported and the standard way for the caller to figure out how much to > allocate before redoing the formatting - as userspace asprintf() and > kernel kasprintf() does. And one of the primary reasons for me to write > the kernel's printf test suite in the first place, as a number of the %p > extensions weren't conforming to that requirement.
Yup, sorry, I was talking from memory, and forgot about the size==0. I've introduced the check of size==0 for seprintf(), but snprintf(3) is okay with it. My bad. The issue with INT_MAX holds. > > 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. > > No, because when passed invalid/bogus input we cannot trust that we can > write anything at all to the buffer. We don't return a negative value, > true, but it's not exactly silent - there's a WARN_ON to help find such > bogus callers. Yup, I know. It's silent to the caller, I meant. > So no, there's "no string at all", but nothing vsnprint() could do in > that situation could help - there's a bug in the caller, we point it out > loudly. Returning -Ewhatever would not remove that bug and would only > make a difference if the caller checked for that. > > We don't want to force everybody to check the return value of snprintf() > for errors, and having an interface that says "you have to check for > errors if your code might be buggy", well... > > In fact, returning -Ewhatever is more likely to make the problem worse; > the caller mismanages buffer/size computations, so probably he's likely > to just be adding the return value to some size_t or char* variable, > making a subsequent use of that variable point to some completely > out-of-bounds memory. That's why seprintf() controls that addition, and gives a pointer directly to the user, which doesn't need to add anything. I think this is easier to handle. There, I can report NULL for bad input, instead of adding 0. Have a lovely day! Alex > > Rasmus -- <https://www.alejandro-colomar.es/>
signature.asc
Description: PGP signature
