On Thu, Aug 27, 2020 at 11:59:24AM +0300, Andy Shevchenko wrote:
strcpy() is not a bad API for the cases when you know what you are doing. A problem that most of the developers do not know what they are doing. No need to split everything to bad and good by its name or semantics, each API has its own pros and cons and programmers must use their brains.
I equate "unsafe" or "fragile" with "bad". There's no reason to use our brains for remembering what's safe or not when we can just remove unsafe things from the available APIs, and/or lean on the compiler to help (e.g. CONFIG_FORTIFY_SOURCE).
Most of the uses of strcpy() in the kernel are just copying between two known-at-compile-time NUL-terminated character arrays. We had wanted to introduce stracpy() for this, but Linus objected to yet more string functions. So for now, I'm aimed at removing strlcpy() completely first, then look at strcpy() -> strscpy() for cases where target size is NOT compile-time known, and then to convert the kernel's strcpy() into _requiring_ that source/dest lengths are known at compile time.
And then tackle strncpy(), which is a mess.