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]>
Hi,

Am 29.11.2025 18:59 schrieb Julia Lawall:
> Sorry, I don't think it is going to work with the attribute in the 
> short
> term.
> 
> I succeeded with the following:
> 
> .cocci
> 
> @r@
> symbol SYSCALL_DEFINE1;
> identifier fn;
> type t;
> position p;
> @@
> fn(int SYSCALL_DEFINE1, ...) {@p ... }
> 
> // or put the corresponding python code
> @script:ocaml@
> p << r.p;
> @@
> 
> Printf.printf "line: %d\n" (List.hd p).line
> 
> ----------------------------------------------
> 
> standard.h
> 
> #define SYSCALL_DEFINE1(func, t1, a1) \
>     int func(int SYSCALL_DEFINE1, t1 a1)
> 
> ----------------------------------------------
> 
> .c
> 
> SYSCALL_DEFINE1(foo,int,x) { return 0; }
> 
> ----------------------------------------------

yep, that worked. Thanks a lot. What also works is to fake the return 
type to syscall_define_t in standard.h, and then do 'type t =~ 
"syscall_define_t";' in the rule.

This is good enough for my experiments *). Sure it would be nice if 
coccinelle could match on "known macros" somehow, maybe during the 
preprocessing run. But as said, I'm not in a position to make such 
suggestions and believe I understand how it's not well suited if the 
engine is designed to match on the AST.

Tobias

*) There's an ongoing effort to add testable code expectations / 
requirements to important functions in the Linux kernel [1]. 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. So I'm looking for 
something that can find all syscalls, all exported symbols, all sysfs 
functions, subset of internal APIs, and so on. 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.

[1] https://lpc.events/event/19/contributions/2085/contribution.pdf
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.