On Sun, Dec 3, 2023 at 6:31 AM Dmitry Dolgov <9erthali...@gmail.com> wrote: > > Only advantage I see to using libclang is that you can run programs built > > with libclang regardless of what your C compiler is. I typically use GCC. > > > > I think your idea of automating this kind of thing is great no matter how it > > is implemented. > > Yeah, absolutely.
What is the difference between a clang plugin (or whatever this is), and a custom clang-tidy check? Are they the same thing? I myself use clang-tidy through clangd. It has a huge number of checks, plus some custom checks that are only used by certain open source projects. An example of a check that seems like it would be interesting to Postgres hackers: https://releases.llvm.org/17.0.1/tools/clang/tools/extra/docs/clang-tidy/checks/bugprone/signal-handler.html An example of a custom clang-tidy check, used for the Linux Kernel: https://releases.llvm.org/17.0.1/tools/clang/tools/extra/docs/clang-tidy/checks/linuxkernel/must-use-errs.html Your idea of starting with a check that identifies when BlockNumber and Buffer variables were confused seems like the right general idea to me. It's just about impossible for this to be a false positive in practice, which is important. But, I wonder, is there a way of accomplishing the same thing without any custom code? Seems like the general idea of not confusing two types like BlockNumber and Buffer might be a generic one? Some random ideas in this area: * A custom check that enforces coding standards within signal handlers -- the generic one that I linked to might need to be customized, in whatever way (don't use it myself). * A custom check that enforces a coding standard that applies within critical sections. We already have an assertion that catches memory allocations made within a critical section. It might make sense to have tooling that can detect other kinds of definitely-unsafe things in critical sections. For example, maybe it would be possible to detect when XLogRegisterBufData() has been passed a pointer to something on the stack that will go out of scope, in a way that leaves open the possibility of reading random stuff from the stack once inside XLogInsert(). AddressSanitizer's use-after-scope can detect that sort of thing, though not reliably. Not at all sure about how feasible any of this is... -- Peter Geoghegan
