Am Freitag, dem 11.07.2025 um 18:45 +0100 schrieb David Laight: > On Fri, 11 Jul 2025 08:05:38 +0200 > Martin Uecker <ma.uec...@gmail.com> wrote: > > > 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: > > What does that actually look like behind all the #defines and generics? > It it continually doing malloc/free it is pretty much inappropriate > for a lot of system/kernel code.
The example I linked would allocate behind your back and would clearly not be useful for the kernel also because it would abort() on allocation failure (as I pointed out below). Still, I do not see why similar functions could not work for the kernel. The main point is to keep pointer and length together in a single struct. But it is certainly more difficult to define APIs which make sense for the kernel. I explain a bit how such types work here: https://uecker.codeberg.page/2025-07-02.html https://uecker.codeberg.page/2025-07-09.html Martin > > > > > 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 > > > > > > > > >
