[theamk]

Are you saying that if you join existing project which uses acuozzo_strzcpy, and you need to do some string copying, instead of using the same functions that everyone already uses, you'll bring your own library and start using flohofwoe_strjcpy in all code _you_ write? (Assuming both of those work on char* types, that is)?

This.. does not seem like a very good idea if you want your contributions to be received well.

[flohofwoe]

I mean, it depends? The fact that it's possible doesn't mean it's a good idea, but at least it's possible. Maybe flohofwoe_strjcpy has a slight performance advantage in an extremely esoteric edge case but extremely hot loop that wasn't considered by acuozzo_strzcpy.

[SleepyMyroslav]

(Not a GP) I think you can see how poorly the string abstraction argument looks in context of a team-based project. Instead of dismissing it completely I would like to provide an example of a context where C is perfectly fine now.

Consider data compression library like Oodle. Even with closed source and use of dangerous things like multiple threads it is perfectly reasonable deal if game project's budget has money to be spent on performance.

The thing is if game project have money it is not likely to be interested in written in C game engines or core middleware libraries (like physics, sound or occlusion culling). Because after buying a license your team is still expected to work in that code even if official support is very active.

Disclaimer, I work in gamedev and never needed to touch C code.