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

Markus Elfring <[email protected]>
Newsgroups fr.inria.cocci
Message-ID <[email protected]>
…>> .c
>>
>> SYSCALL_DEFINE1(foo,int,x) { return 0; }
…> yep, that worked.

Thanks for your indication of an usable outcome.


> 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.


> 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.


> But as said, I'm not in a position to make such suggestions

Please reconsider such a view once more.


> 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.

Regards,
Markus
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.