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
