From: Markus Elfring <Markus.Elfring@web.de>
To: Tobias Deiminger <tobias.deiminger@posteo.de>
Cc: cocci@inria.fr
Subject: Re: [cocci] Can we match a known macro by macro name instead of expanded function name?
Date: Sun, 30 Nov 2025 09:05:51 +0100 [thread overview]
Message-ID: <e88c503c-b2a1-454b-a4a4-ae2dedd79daf@web.de> (raw)
In-Reply-To: <ded004b275d73e35c46c3d30c057d58e@posteo.de>
…>> .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
next prev parent reply other threads:[~2025-11-30 8:06 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-29 10:38 [cocci] Can we match a known macro by macro name instead of expanded function name? Tobias Deiminger
2025-11-29 10:56 ` Julia Lawall
2025-11-29 13:15 ` Tobias Deiminger
2025-11-29 13:32 ` Markus Elfring
2025-11-29 13:51 ` Julia Lawall
2025-11-29 14:51 ` Markus Elfring
2025-11-29 15:00 ` Julia Lawall
2025-11-29 15:10 ` [cocci] Questionable macro expansions Markus Elfring
2025-11-29 15:55 ` [cocci] Can we match a known macro by macro name instead of expanded function name? Tobias Deiminger
2025-11-29 15:59 ` Julia Lawall
[not found] ` <67d1e00d2e22a4655cb10ec55d1a99db@posteo.de>
[not found] ` <83c8a7aa-9b98-8ac1-d563-e8fe2588f9a@inria.fr>
[not found] ` <fd7307f8024706d4bd128d0b7f43bb96@posteo.de>
2025-11-29 17:33 ` Tobias Deiminger
2025-11-29 17:38 ` Markus Elfring
2025-11-29 17:59 ` Julia Lawall
2025-11-29 18:28 ` Markus Elfring
2025-11-29 18:41 ` Julia Lawall
2025-11-29 19:00 ` Markus Elfring
2025-11-29 20:06 ` Tobias Deiminger
2025-11-29 20:10 ` Julia Lawall
2025-11-30 8:44 ` [cocci] Clarification for parsing capabilities? Markus Elfring
2025-11-30 8:05 ` Markus Elfring [this message]
2025-11-30 19:02 ` [cocci] Can we match a known macro by macro name instead of expanded function name? Tobias Deiminger
2025-12-01 8:32 ` Tobias Deiminger
2025-12-01 14:00 ` Markus Elfring
2025-12-01 9:42 ` Markus Elfring
2025-12-04 8:50 ` [cocci] Searching for system call implementations? Markus Elfring
2025-11-29 16:28 ` [cocci] Can we match a known macro by macro name instead of expanded function name? Markus Elfring
2025-12-02 9:45 ` [cocci] Searching for system call implementations with SmPL? Markus Elfring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e88c503c-b2a1-454b-a4a4-ae2dedd79daf@web.de \
--to=markus.elfring@web.de \
--cc=cocci@inria.fr \
--cc=tobias.deiminger@posteo.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox