Jeff King <p...@peff.net> writes: > For enforcement, we can rely on the compiler and just > introduce code which breaks compilation when it sees these > functions. This has a few advantages: > > 1. We know it's run as part of a build cycle, so it's > hard to ignore. Whereas an external linter is an extra > step the developer needs to remember to do. > > 2. Likewise, it's basically free since the compiler is > parsing the code anyway. > > 3. We know it's robust against false positives (unlike a > grep-based linter). > > The one big disadvantage is that it will only check code > that is actually compiled, so it may miss code that isn't > triggered on your particular system. But since presumably > people don't add new code without compiling it (and if they > do, the banned function list is the least of their worries), > we really only care about failing to clean up old code when > adding new functions to the list. And that's easy enough to > address with a manual audit when adding a new function > (which is what I did for the functions here). > > That leaves only the question of how to trigger the > compilation error. The goals are:
I actually have another question, though. Is it a downside that it is cumbersome to override? This is not a rhetorical question. I am not convinced there will not be a legit circumstance that calling strcpy (or whatever we are going to ban) is the best solution and it is safe. By "best", what I mean is "you could instead use memcpy/strncpy/whatever" can legitimately be argued with "but still using memcpy/strncpy/whatever is inferior than using strcpy in this case for such and such reasons".
