Re: [RFC] Clang plugin for catching suspicious typedef casting - Mailing list pgsql-hackers

From Dmitry Dolgov
Subject Re: [RFC] Clang plugin for catching suspicious typedef casting
Date
Msg-id 20230809163224.63yra5b4enim7srk@erthalion.local
Whole thread Raw
In response to Re: [RFC] Clang plugin for catching suspicious typedef casting  (Peter Eisentraut <peter@eisentraut.org>)
Responses Re: [RFC] Clang plugin for catching suspicious typedef casting
List pgsql-hackers
> On Wed, Aug 09, 2023 at 03:23:32PM +0200, Peter Eisentraut wrote:
> On 03.08.23 18:56, Dmitry Dolgov wrote:
> > I would like to get your opinion, folks. Does it sound interesting
> > enough for the community, is it worth it to pursue the idea?
>
> I think it's interesting, and doesn't look too invasive.
>
> Maybe we can come up with three or four interesting use cases and try to
> implement them.  BlockNumber vs. Buffer type checking is obviously a bit
> marginal to get anyone super-excited, but it's a reasonable demo.
>
> Also, how stable is the plugin API?  Would we need to keep updating these
> plugins for each new clang version?

From the first glance the API itself seems to be stable -- I didn't find
many breaking changes for plugins in the release notes over the last
five releases. The git history for such definitions as ASTConsumer or
RecursiveASTVisitor also doesn't seem to be very convoluted.

But libreoffice example shows, that some updating would be necessary --
they've got about a dozen of places in the code that depend on the clang
version. From what I see it's usually not directly related to the plugin
API, and looks more like our opaque pointers issue.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Adding a pg_servername() function
Next
From: Tom Lane
Date:
Subject: Re: Using defines for protocol characters