Not necessarily. There are implementations which don't even take advantage of 4/8 byte copying. We wanted to have something uniform. But yes, you are right with glibc or macOS.
Also, from the strncpy man page:
strlcpy()
Some systems (the BSDs, Solaris, and others) provide the following function:
size_t strlcpy(char *dest, const char *src, size_t size);
This function is similar to strncpy(), but it copies at most size-1 bytes to dest, always adds a
terminating null byte, and does not pad the target with (further) null bytes. This function
fixes some of the problems of strcpy() and strncpy(), but the caller must still handle the possi‐
bility of data loss if size is too small. The return value of the function is the length of src,
which allows truncation to be easily detected: if the return value is greater than or equal to
size, truncation occurred. If loss of data matters, the caller must either check the arguments
before the call, or test the function return value. strlcpy() is not present in glibc and is not
standardized by POSIX, but is available on Linux via the libbsd library.
I'm not sure which specific excerpt you're referring to, but I have a good idea of the many functions that libraries have come up with to sling characters from one buffer to another, plus I read your implementation and the man page snippet you linked above. I'm still not seeing why you can't replace the code between lines 881 and 902 with one of the appropriate copying routines; you quite literally have a source, destination, and length and you can fix up the last NUL byte right after the call. The standard library's function will be vectorized regardless of how your compiler was feeling that day, and it's probably smarter than yours (glibc, for example, does a "small copy" up to alignment before it launches into the vectorized stuff, rather than skipping it entirely if the buffers aren't aligned). And your function does have undefined behavior: you pun a char * to a ulong *.
> The standard library's function will be vectorized regardless of how your compiler was feeling that day
We talked glibc. I mentioned there are libraries which do not do _any_ optimization other than a byte by byte copy.
> I'm still not seeing why you can't replace the code between lines 881 and 902
Because you are considering only glibc.
And yes, we can do a lot of things. But the function and copying buffers are not the top priority for us ATM. I shared it as an example in the context of the current topic. Not all code is supposed to match your preferences.
> char * to a ulong *
Both the source and destination are guarded by length and alignment requirement checks.