Re: [RFC] Clang plugin for catching suspicious typedef casting

On Sun, Dec 3, 2023 at 6:31 AM Dmitry Dolgov <9erthalion6@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