This is a patch series to address the discussion in the thread at: https://public-inbox.org/git/20180713204350.GA16999@xxxxxxxxxxxxxxxxxxxxx/ Basically, the question was: can we declare strcpy banned and have a linter save us the trouble of finding it in review. The answer is yes, the compiler is good at that. ;) There are probably as many lists of banned functions as there are coding style documents. I don't agree with every entry in the ones I've seen. And in many cases coccinelle is a better choice, because the problem is not "this function is so bad your patch should not even make it to the list with it", but "don't do it like A; we prefer to do it like B instead". And coccinelle does the latter more flexibly and automatically. So I tried to pick some obvious and uncontroversial candidates here. gets() could be another one, but it's mostly banned already (it's out of the standard, and most libcs mark it with a deprecated attribute). Note that this needs to be applied on top of 022d2ac1f3 (blame: prefer xsnprintf to strcpy for colors, 2018-07-13) or it will complain loudly. :) [1/2]: introduce "banned function" list [2/2]: banned.h: mark strncpy as banned Documentation/CodingGuidelines | 3 +++ banned.h | 20 ++++++++++++++++++++ git-compat-util.h | 2 ++ 3 files changed, 25 insertions(+) create mode 100644 banned.h -Peff
