Re: Coccinelle for PostgreSQL development [4/N]: correcting palloc() use - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Coccinelle for PostgreSQL development [4/N]: correcting palloc() use
Date
Msg-id 0839314f-236b-4215-8276-2f4f6f4462c0@eisentraut.org
Whole thread Raw
Responses Re: Coccinelle for PostgreSQL development [4/N]: correcting palloc() use
List pgsql-hackers
On 07.01.25 20:49, Mats Kindahl wrote:
> This is the first example semantic patch and shows how to capture and 
> fix a common problem.
> 
> If you use an palloc() to allocate memory for an object (or an array of 
> objects) and by mistake type something like:
> 
>      StringInfoData *info = palloc(sizeof(StringInfoData*));
> 
> You will not allocate enough memory for storing the object. This 
> semantic patch catches any cases where you are either allocating an 
> array of objects or a single object that do not have corret types in 
> this sense, more precisely, it captures assignments to a variable of 
> type T* where palloc() uses sizeof(T) either alone or with a single 
> expression (assuming this is an array count).
> 
> The semantic patch is overzealous in the sense that allocation to a 
> "const char **" expects a "sizeof(const char *)" and it cannot deal with 
> typedefs that introduce aliases (these two can be seen in the patch). 
> Although the sizes of these are the same, and Coccinelle do not have a 
> good system for comparing types, it might be better to just follow the 
> convention of always using the type "T*" for any "palloc(sizeof(T))" 
> since it makes automated checking easier and is a small inconvenience; 
> especially considering that coccicheck can easily fix this for you. It 
> also simplifies other automated checking to follow this convention.

I think this kind of thing is better addressed with a static analyzer or 
some heavier compiler annotations and warnings or something like that. 
That kind of tool would have the right level of information to decide 
whether some code is correct.  Having a text matching tool do it is just 
never going to be complete, and the problems you mention show that this 
tool fundamentally doesn't understand the code, and just knows how to 
parse the code a little better than grep or sed.

I do like the idea of exploring this tool for facilitating code 
rewriting or semantic patching.  But I'm suspicious about using it for 
enforcing coding styles or patterns.




pgsql-hackers by date:

Previous
From: Guillaume Lelarge
Date:
Subject: Re: Non-text mode for pg_dumpall
Next
From: Bruce Momjian
Date:
Subject: Re: Parameter NOT NULL to CREATE DOMAIN not the same as CHECK (VALUE IS NOT NULL)