On Thu, Jul 19, 2018 at 09:08:08PM -0400, Jeff King wrote: > Ditto for sprintf, where you should _always_ be using at least xsnprintf > (or some better tool, depending on the situation). And for strncpy, > strlcpy (or again, some better tool) is strictly an improvement. Nitpick: this may be true for git, but it's not strictly true in all cases. I actually have a (non-git) case where strncpy *is* the right tool. And this is one where I'm copying a NUL-terminated string into a fixed-length charater array (in the ext4 superblock) which is *not* NUL-terminated. In that case, strncpy works(); but strlcpy() does not do what I want. So I used strncpy() advisedly, and I ignore people running Coccinelle scripts and blindly sending patches to "fix" ext4. But perhaps that's also a solution for git? You don't have to necessarily put them on a banned list; you could instead have some handy, pre-set scripts that scan the entire code base looking for "bad" functions with cleanups automatically suggested. This could be run at patch review time, and/or periodically (especially before a release). - Ted
