Because a C "string" is a char* by convention, any time a library exposes string parameters that's what they use. This includes libraries not written in C! I ca

Because a C "string" is a char* by convention, any time a library exposes string parameters that's what they use. This includes libraries not written in C! I can't even think of a counter-example. Using an own string type adds too much friction, particularly because it prevents automatic binding generation. With errors such a standard doesn't even exist so you get a mess. And yes, as a library developer you need to signal errors somehow, and whichever solution you use, the binding generator doesn't know about it. Rust has a nice error propagation mechanism which lets me attempt a set of operations but abort early when an error happens, but the binding generator can't use it. Namespaces are a similar problem, they force library devs to try and come up with unique but short prefixes. Had C had namespaces the "short" constraint wouldn't be a problem, pretty much eliminating the chance of collision. Am I right in assuming you're an embedded developer? Typically when I have this discussion with people the points that you make come from embedded devs. They're not reflective of the needs of library developers.