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

Tobias Deiminger <[email protected]>
Newsgroups fr.inria.cocci
Message-ID <[email protected]>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.