Re: [cocci] Can we match a known macro by macro name instead of expanded function name?

[Tobias Deiminger <tobias.deiminger@posteo.de>]

Hi,

Am 30.11.2025 09:05 schrieb Markus Elfring:
>> What also works is to fake the return type to syscall_define_t in 
>> standard.h,
> 
> I became curious if such observations can be clarified further.

I observed this while looking for standard.h modifications that avoid 
numbering 1..6 in the 12 macro variants, so that there can be 1 simple 
common rule for all 12 variants.

 From Julia's example I found by trial that macro name and first 
parameter must have same name, otherwise it wouldn't work:

   // standard.h, try either 1st or 2nd line
   #define SYSCALL_DEFINE1(func, t1, a1) int func(int SYSCALL_DEFINE1, t1 
a1)  // works
   #define SYSCALL_DEFINE1(func, t1, a1) int func(int SYSCALL_DEFINE, t1 
a1)  // doesn't work (rule adjusted, or course)

Can you explain why the 2nd doesn't work? Looks like if there was some 
conventional relation between macro name and first parameter.

>> and then do 'type t =~ "syscall_define_t";' in the rule.
> 
> I would like to point out that mentioned implementation details can be 
> refined.
> I suggest to reconsider the need for the specification of an SmPL 
> constraint
> as a regular expression just for the selection of a single identifier.

Indeed, thanks! Selecting a specific type in the semantic patch didn't 
work on first try. Meanwhile I figured one needs to add a typedef to the 
meta declaration - then it works and I can avoid the regex.

>> But as said, I'm not in a position to make such suggestions
> 
> Please reconsider such a view once more.

So far I think Coccinelle is an amazing tool.

Macro handling maybe was a bit surprising, quoting Julia: "Coccinelle 
expands macros when it has them available and when it is not able to 
parse the code without doing the expansion". As a user I have to know if 
a macro will be expanded or not, since match patterns have to look 
different accordingly. But the exact conditions for expansion are not 
too easy to anticipate.

>> and believe I understand how it's not well suited if the engine is 
>> designed to match on the AST.
> 
> The understanding is still improvable.
> Various development challenges are involved.
> 
> 
>> *) There's an ongoing effort to add testable code expectations / 
>> requirements to important functions in the Linux kernel [1].
> 
> Thanks for such background information.
> 
> Linux Plumbers Conference
> Adding Testable Code Specifications in the Linux Kernel
> https://lpc.events/event/19/contributions/2085/
> 
> 
>> I'm involved, and one thing that IMO would help is if we could 
>> quantify what "important" exactly means, i.e. how many functions are 
>> to be documented (100? 10000? 1000000?), and where exactly are they.
> 
> Software documentation is also a known challenging topic.
> 
> Special constraints can become more interesting when even macro 
> definitions
> need to be taken better into account.
> 
> 
>> Raw grep is obviously not well suited. Coccinelle is already used for 
>> similar tasks, so it's an obvious candidate. tree-sitter queries could 
>> also work.
> 
> There are promising software tools available.

Probably :) Do you have other suggestions?

Tobias