Even back in the day, I regarded unsafe functions such as strcpy() as nothing more than courtesies by the stdlib providers. I assumed it was up to me to write my own libraries for strings, linked lists, concurrency and so on precisely because they weren't reentrant or memory-safe.
Fast forward to today. Has anything changed? If I decide to use C89 or C11 for a project, aren't I still responsible for my own string allocation/comparison duties, etc.? Aren't I just going to roll my own string structure type with its own size_t length value along with a terminating 0 byte for compat and invent or find a Unicode library?
In other words, are all these complaints people have just nature of C, or is there something about C development that's changed fundamentally in the last couple of decades?
[0]: https://github.com/git/git/blob/master/banned.h
If I have to do that work I begin to ask “do I _really_ want to work in this environment where I have to maintain this kinda stuff?”
> (and even if used correctly complicate audits).
With correctness-sensitive and security-sensitive C programs like Git, it is not enough to simply assume flawless diligence and care on the part of the developers (especially since the unsafe functions are very convenient and can easily slip in to production code during testing or prototyping).
So “banned.h” is really an automated auditing tool: at a quick glance, Git users can verify that large families of C bugs are much less likely throughout the Git codebase (and many standard strlen/etc bugs are obviously impossible).