Technically strncpy was invented to interact with null-padded fixed-size strings in general. We’ve mostly (though not entirely) moved away from them but fixed-size strings used to be very common. You can see them all over old file formats still.

It’s also horrible because each project ends up reinventing their own abstractions or solutions for dealing with common things.

Destroys a lot of opportunity for code reuse / integration. Especially within a company.

Alternatively their code base remains a steaming pile of crap riddled with vulnerabilities.

That's how everything works. You start off with some atomics and build up from there. Things that people like get standardized, And before you know what's going on it's called stdlib.

It took a decade between Stroustrup's 1985 book "The C++ Programming Language" and the STL proposed and accepted by the ANSI/ISO committee in 1994.

Yeah but those standard libraries are still inadequate 30 years later.

Imagine a hypothetical Python scenario where every application and library had their own list implementations with differently named methods and behavior.

Yet C is exactly that. Is it not common place to log messages to a file? How many applications and code bases DO NOT use syslog(). And if one wants to use syslog, then assert failures won’t get logged there…

Sure, with a custom assertion and logging framework one can get reasonable behavior. But it’s not automatic. Hence, a Tower of Babel …

That's Linux C you're talking about. Many, many, many C codebases don't use syslog.

Exactly!

At least Python has a standardized “logging” module where applications can control the format and destination.

But with the standard C library, there is little common ground. Solutions to the same basic problems are constantly reinvented - differently.

I've always assumed that the n in strncpy was meant to signify a max length N. Now I'm wondering if it might have stood for NUL padding.