Am 04.01.2025 um 12:15 schrieb Johnny Billquist: > The language, or functions, does not solve the problems, or make > anything safe. The programmer needs to know what he is doing, and he can > do things wrong in any environment if he don't know.
I object. In any mature system, I expect that there are time-tested functions for everyday tasks, and I expect that these functions guide programmers into using them correctly, as far as possible. If the system does not provide functions to solve everyday tasks efficiently, we get exactly the situation we are in right now, in that the general-purpose always-available functions strncpy and strlcpy are used to approximately achieve the desired result. The beauty of copyin/copyout is that there is no way around them. For the string functions, the situation is different, as the standard C library and POSIX provide plenty of functions to choose from, but these are general-purpose and thus may or may not be suited to the task at hand. > On 2025-01-04 11:14, David Holland wrote: >> maybe something like >> >> strlcpy_tofixed(char *dest, size_t destlen, const char *src); >> strlcpy_fromfixed(char *dest, size_t destmax, const char *src, size_t >> srclen); >> >> and >> >> strlcpy_zerofill(char *dest, const char *src, size_t destmax); I like these proposals, as their names clearly communicate their purpose, and when looking at the code during an audit, I can quickly see that the copying takes place correctly, by looking at only a single function call. The functions should not be called "strlcpy" though, as that implies that they perform a strlen(src). Simply calling them "strcpy" should suffice. The size_t parameters should all be called "size" instead of "len" or "max". In the code snippets from my first post to this discussion, I couldn't locally see that the strings are null-terminated, or whether they are intended to be null-terminated at all. But I wanted to see this, to gain confidence that there are no unwanted buffer overflows or other vulnerabilities. Roland
