On Thu, Jul 19, 2018 at 04:32:59PM -0400, Jeff King wrote: > 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. ;) Here's a v2 that I think addresses the comments on the earlier series. Thanks everybody for your review. Changes here include: - drop the mention in CodingGuidelines. That list is already long, and we don't need to to waste mental effort on things that will be enforced automatically - we now #undef all macros before defining them to avoid redefinition warnings - the first patch now covers _just_ strcpy(), and each function gets its own patch with an explanation (and suggested alternatives). My thought is that these should be easy to dig up via blame, "log -S", or "log --grep". Though another option would be comments in banned.h. - added strcat and vsprintf to the banned list - tweaked the first patch's commit message for clarity and to address points raised in discussion As before, this needs to go on top of 022d2ac1f3 (which I hope should hit master soon anyway). [1/4]: automatically ban strcpy() [2/4]: banned.h: mark strcat() as banned [3/4]: banned.h: mark sprintf() as banned [4/4]: banned.h: mark strncpy() as banned banned.h | 30 ++++++++++++++++++++++++++++++ git-compat-util.h | 6 ++++++ 2 files changed, 36 insertions(+) create mode 100644 banned.h -Peff
