Am Donnerstag, dem 10.07.2025 um 14:58 -0700 schrieb Linus Torvalds: > On Thu, 10 Jul 2025 at 14:31, Alejandro Colomar <a...@kernel.org> wrote: > > > > These macros are essentially the same as the 2-argument version of > > strscpy(), but with a formatted string, and returning a pointer to the > > terminating '\0' (or NULL, on error). > > No. > > Stop this garbage. > > You took my suggestion, and then you messed it up. > > Your version of sprintf_array() is broken. It evaluates 'a' twice. > Because unlike ARRAY_SIZE(), your broken ENDOF() macro evaluates the > argument. > > And you did it for no reason I can see. You said that you wanted to > return the end of the resulting string, but the fact is, not a single > user seems to care, and honestly, I think it would be wrong to care. > The size of the result is likely the more useful thing, or you could > even make these 'void' or something. > > But instead you made the macro be dangerous to use. > > This kind of churn is WRONG. It _looks_ like a cleanup that doesn't > change anything, but then it has subtle bugs that will come and bite > us later because you did things wrong. > > I'm NAK'ing all of this. This is BAD. Cleanup patches had better be > fundamentally correct, not introduce broken "helpers" that will make > for really subtle bugs. > > Maybe nobody ever ends up having that first argument with a side > effect. MAYBE. It's still very very wrong. > > Linus
What I am puzzled about is that - if you revise your string APIs -, you do not directly go for a safe abstraction that combines length and pointer and instead keep using these fragile 80s-style string functions and open-coded pointer and size computations that everybody gets wrong all the time. String handling could also look like this: https://godbolt.org/z/dqGz9b4sM and be completely bounds safe. (Note that those function abort() on allocation failure, but this is an unfinished demo and also not for kernel use. Also I need to rewrite this using string views.) Martin
