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

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

Am 30.11.2025 20:02 schrieb Tobias Deiminger:
>>> 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.

Sadly, what I said above (adding typedef) only works when calling spatch 
for one specific .c file. It fails when using --dir to recursively scan 
the source tree.

What seems to happen with --dir and using the following rule

@r@
typedef syscall_define_t;
identifier fn;
@@
syscall_define_t fn(...) {...}

is that spatch filters .c files early by raw text search for 
"syscall_define_t", before it actually processes patterns. In my case, 
"syscall_define_t" is not written to .c, but to the built-in macro file. 
The raw text search in .c fails, and the .c file is wrongly filtered 
out.

To verify my hypothesis, simply adding a comment line "// 
syscall_define_t" to the .c file is enough to trick spatch into not 
skipping the file and applying the rule correctly.

This almost appears like a bug. Can you think of a workaround?

Tobias