Even if you have functionally unlimited money like Apple, it’s tough to prioritize rewriting a somewhat obscure piece of the OS solely to prevent security issues. Because if you have a team that’s capable of fully reimplementing this component, and getting it through a QA process to make sure it doesn’t break another component of the OS…well damn, that’s a team you probably want on a higher-profile project, and not doing cleanup, right?
The options were always there since around 1958, then about 15 years later, a group of folks doing their tiny OS decided to ignore them when creating their fun little language, because it was more fun to do their own thing.
The problem is that this tiny OS and accompaning language grew to be everywhere thanks to its license, so now we are in this mess.
But options? They have always been there for those that actually care.
But that’s me being argumentative. 100% agree for “system software” like this.
C's strings are zero byte terminated, but the strings strncpy() is intended to target are not, they're file names in a fixed length buffer. So, it's fine to fill the entire buffer with text and no terminator, or to write a single byte of text, and fill the rest with zero bytes. If that's the exact problem you have, strncpy() is the exact feature you wanted. Otherwise it isn't.
If you aren't aware of why Unix wanted this feature it's a very strange thing to find in C's small standard library.
(Beating a dead horse, I know, and not blaming the devs because this utility has been around forever, but regardless)