Re: Coccinelle for PostgreSQL development [1/N]: coccicheck.py - Mailing list pgsql-hackers
From | Andrew Dunstan |
---|---|
Subject | Re: Coccinelle for PostgreSQL development [1/N]: coccicheck.py |
Date | |
Msg-id | 27a573c0-70f0-4d5c-b9ca-d8c4e2b999f6@dunslane.net Whole thread Raw |
Responses |
Re: Coccinelle for PostgreSQL development [1/N]: coccicheck.py
|
List | pgsql-hackers |
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. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
pgsql-hackers by date: