I think this might be the part from banned.h that you’re missing: > (and even if used correctly complicate audits). With correctness-sensitive and security-se

I think this might be the part from banned.h that you’re missing: > (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).