Re: Coccinelle for PostgreSQL development [1/N]: coccicheck.py

From: Mats Kindahl <mats(at)timescale(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Coccinelle for PostgreSQL development [1/N]: coccicheck.py
Date: 2025-01-08 11:40:50
Message-ID: CA+14427gUW_OHPSCbzd2-LtTya+mCtH5TftBbRfrhvk1LZr1Ag@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jan 8, 2025 at 11:42 AM Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:

>
> On 2025-01-07 Tu 2:44 PM, Mats Kindahl wrote:
> > I got some time over during the holidays, so I spent some of it
> > doing something I've been thinking about for a while.
> >
> > For those of you that are not aware of it: Coccinelle is a tool for
> > pattern matching and text transformation for C code and can be used
> > for detection of problematic programming patterns and to make complex,
> > tree-wide patches easy. It is aware of the structure of C code and is
> > better suited to make complicated changes than what is possible using
> > normal text substitution tools like Sed and Perl.
> >
> > Coccinelle have been successfully been used in the Linux project since
> > 2008 and is now an established tool for Linux development and a large
> > number of semantic patches have been added to the source tree to
> > capture everything from generic issues (like eliminating the redundant
> > A in expressions like "!A || (A && B)") to more Linux-specific
> > problems like adding a missing call to kfree().
> >
> > Although PostgreSQL is nowhere the size of the Linux kernel, it is
> > nevertheless of a significant size and would benefit from
> > incorporating Coccinelle into the development. I noticed it's been
> > used in a few cases way back (like 10 years back) to fix issues in the
> > PostgreSQL code, but I thought it might be useful to make it part of
> > normal development practice to, among other things:
> >
> > - Identify and correct bugs in the source code both during development
> > and review.
> > - Make large-scale changes to the source tree to improve the code
> > based on new insights.
> > - Encode and enforce APIs by ensuring that function calls are used
> > correctly.
> > - Use improved coding patterns for more efficient code.
> > - Allow extensions to automatically update code for later PostgreSQL
> > versions.
> >
> > To that end, I created a series of patches to show how it could be
> > used in the PostgreSQL tree. It is a lot easier to discuss concrete
> > code and I split it up into separate messages since that makes it
> > easier to discuss each individual patch. The series contains code to
> > make it easy to work with Coccinelle during development and reviews,
> > as well as examples of semantic patches that capture problems,
> > demonstrate how to make large-scale changes, how to enforce APIs, and
> > also improve some coding patterns.
> >
> > This first patch contains the coccicheck.py script, which is a
> > re-implementation of the coccicheck script that the Linux kernel uses.
> > We cannot immediately use the coccicheck script since it is quite
> > closely tied to the Linux source code tree and we need to have
> > something that both supports autoconf and Meson. Since Python seems to
> > be used more and more in the tree, it seems to be the most natural
> > choice. (I have no strong opinion on what language to use, but think
> > it would be good to have something that is as platform-independent as
> > possible.)
> >
> > The intention is that we should be able to use the Linux semantic
> > patches directly, so it supports the "Requires" and "Options"
> > keywords, which can be used to require a specific version of spatch(1)
> > and add options to the execution of that semantic patch, respectively.
> >
>
>
> Please don't start multiple threads like this. If you want to submit a
> set of patches for a single feature, send them all as attachments in a
> single email. Otherwise this just makes life hard for threading email
> readers.
>

My apologies, I thought this would make it easier to discuss and review the
code. I will send a single email in the future.

Should I resend this as a single email with all the patches?
--
Best wishes,
Mats Kindahl, Timescale

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Rahila Syed 2025-01-08 12:03:01 Re: Enhancing Memory Context Statistics Reporting
Previous Message Daniel Gustafsson 2025-01-08 11:35:47 Re: Moving the vacuum GUCs' docs out of the Client Connection Defaults section