Description
In llvm/llvm-project#57954, the LLVM/Clang developers make it clear that they are strongly opposed to using the preprocessor in the way that we do to mark functions such as strncpy() as deprecated.
Initially, I did not consider their arguments to be persuasive, but then I posed the question:
Is there any possible way that the macro definition here would cause the wrong thing to be emitted by the toolchain as a binary, especially when the function is not used (which is the the purpose of the macro definition)?
To which, @erichkeane replied:
Yes, in some implementations (ours included!) a number of standard library functions are implemented as builtins that either emit code directly, or via certain system calls. Defining it to only 'sometimes' match that definition could cause inlined versions of this function to not 'do the right thing'.
It sounds like compiler optimizations can cause the checks defined in config/Rules.am that are intended to ban certain functions from the codebase to fail to cause build failures when they are used. Thus, the mechanism should be replaced.
Two competing ideas that I have for replacing it are:
- Modify cstyle.pl to catch it.
- Modify CodeQL to catch it.