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

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

[Tobias Deiminger]

Hi,

my newbie assumption was we could match the following by macro name

   // my.c
   SYSCALL_DEFINE0(foo_bar) { return; }

using this rules

   // my.cocci
   @r@
   identifier fn =~ "SYSCALL_DEFINE[0-6]+";
   position p;
   @@
   fn@p(...) {...}

   @script:python@
   fn << r.fn;
   p << r.p;
   @@
   print(f"match: {fn} at line {p[0].current_element_line}")


Turns out, SYSCALL_DEFINE0 is a "known macro" from 
/usr/lib/coccinelle/standard.h. In this case coccinelle seems to match 
an identifier on the expanded function name, not the macro name. I.e., 
this would work:

   identifier fn =~ "foo.*";

But I really want to search all syscalls by the conventional macro 
names, i.e. search for SYSCALL_DEFINE[0-6]+. How to do that?

Tobias

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

[Julia Lawall]

On Sat, 29 Nov 2025, Tobias Deiminger wrote:

> Hi,
>
> my newbie assumption was we could match the following by macro name
>
>   // my.c
>   SYSCALL_DEFINE0(foo_bar) { return; }
>
> using this rules
>
>   // my.cocci
>   @r@
>   identifier fn =~ "SYSCALL_DEFINE[0-6]+";
>   position p;
>   @@
>   fn@p(...) {...}
>
>   @script:python@
>   fn << r.fn;
>   p << r.p;
>   @@
>   print(f"match: {fn} at line {p[0].current_element_line}")
>
>
> Turns out, SYSCALL_DEFINE0 is a "known macro" from
> /usr/lib/coccinelle/standard.h. In this case coccinelle seems to match an
> identifier on the expanded function name, not the macro name. I.e., this would
> work:
>
>   identifier fn =~ "foo.*";
>
> But I really want to search all syscalls by the conventional macro names, i.e.
> search for SYSCALL_DEFINE[0-6]+. How to do that?

The problem is that the code won't parse with the conventional macro
name.  Maybe you could change the macro definition in standard.h to put eg
__SYSCALL_DEFINE0 in front of the function name?  That would be considered
to be an attribute and then you could put __SYSCALL_DEFINE0 as an
attribute name in your semantic patch.

The position also can't be on the expanded part.  That will give you a
position in standard.h.  Just move it to the {

julia

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

[Tobias Deiminger]

Hi Julia,

Am 29.11.2025 11:56 schrieb Julia Lawall:
> On Sat, 29 Nov 2025, Tobias Deiminger wrote:
> 
>> Hi,
>> 
>> my newbie assumption was we could match the following by macro name
>> 
>>   // my.c
>>   SYSCALL_DEFINE0(foo_bar) { return; }
>> 
>> using this rules
>> 
>>   // my.cocci
>>   @r@
>>   identifier fn =~ "SYSCALL_DEFINE[0-6]+";
>>   position p;
>>   @@
>>   fn@p(...) {...}
>> 
>>   @script:python@
>>   fn << r.fn;
>>   p << r.p;
>>   @@
>>   print(f"match: {fn} at line {p[0].current_element_line}")
>> 
>> 
>> Turns out, SYSCALL_DEFINE0 is a "known macro" from
>> /usr/lib/coccinelle/standard.h. In this case coccinelle seems to match 
>> an
>> identifier on the expanded function name, not the macro name. I.e., 
>> this would
>> work:
>> 
>>   identifier fn =~ "foo.*";
>> 
>> But I really want to search all syscalls by the conventional macro 
>> names, i.e.
>> search for SYSCALL_DEFINE[0-6]+. How to do that?
> 
> The problem is that the code won't parse with the conventional macro
> name.  Maybe you could change the macro definition in standard.h to put 
> eg
> __SYSCALL_DEFINE0 in front of the function name?  That would be 
> considered
> to be an attribute and then you could put __SYSCALL_DEFINE0 as an
> attribute name in your semantic patch.

sorry for having to ask again. Your suggestion sounds very reasonable. 
But I couldn't figure out how to match on attributes. I guessed it would 
be something like this

   @r@
   attribute a;
   identifier fn;
   @@

   a fn(...) { ... }

But that gives a .cocci parse error:

   minus: parse error:
     File "my.cocci", line 6, column 2, charpos = 38
     around = 'fn',
     whole content = a fn(...) { ... }

Expected, IIUC, since attribute doesn't occur in fundecl from grammar:

   fundecl ::=  [fn_ctype] funinfo * funid ([PARAMSEQ(param, ε)]) { 
[stmt_seq] }

How else to look for functions with attributes then?

Tobias

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

[Markus Elfring]

>> The problem is that the code won't parse with the conventional macro
>> name.  Maybe you could change the macro definition in standard.h to put eg
>> __SYSCALL_DEFINE0 in front of the function name?  That would be considered
>> to be an attribute and then you could put __SYSCALL_DEFINE0 as an
>> attribute name in your semantic patch.
> 
> sorry for having to ask again. Your suggestion sounds very reasonable.

Please take also another look at a corresponding information source.
https://gitlab.inria.fr/coccinelle/coccinelle/-/blob/4c9d00ae071800cb447efaffd753f3bb2be28800/docs/manual/cocci_syntax.tex#L255-256


> But I couldn't figure out how to match on attributes. I guessed it would be something like this
> 
>   @r@
>   attribute a;
>   identifier fn;
>   @@
> 
>   a fn(...) { ... }
> 
> But that gives a .cocci parse error:

You might point remaining improvement possibilities out for this evolving software.

How do you think about to try the metavariable type “attribute name” out
for the mentioned source code search approach?

Regards,
Markus

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

[Julia Lawall]

[-- Attachment #1: Type: text/plain, Size: 2211 bytes --]



On Sat, 29 Nov 2025, Tobias Deiminger wrote:

> Hi Julia,
>
> Am 29.11.2025 11:56 schrieb Julia Lawall:
> > On Sat, 29 Nov 2025, Tobias Deiminger wrote:
> >
> > > Hi,
> > >
> > > my newbie assumption was we could match the following by macro name
> > >
> > >   // my.c
> > >   SYSCALL_DEFINE0(foo_bar) { return; }
> > >
> > > using this rules
> > >
> > >   // my.cocci
> > >   @r@
> > >   identifier fn =~ "SYSCALL_DEFINE[0-6]+";
> > >   position p;
> > >   @@
> > >   fn@p(...) {...}
> > >
> > >   @script:python@
> > >   fn << r.fn;
> > >   p << r.p;
> > >   @@
> > >   print(f"match: {fn} at line {p[0].current_element_line}")
> > >
> > >
> > > Turns out, SYSCALL_DEFINE0 is a "known macro" from
> > > /usr/lib/coccinelle/standard.h. In this case coccinelle seems to match an
> > > identifier on the expanded function name, not the macro name. I.e., this
> > > would
> > > work:
> > >
> > >   identifier fn =~ "foo.*";
> > >
> > > But I really want to search all syscalls by the conventional macro names,
> > > i.e.
> > > search for SYSCALL_DEFINE[0-6]+. How to do that?
> >
> > The problem is that the code won't parse with the conventional macro
> > name.  Maybe you could change the macro definition in standard.h to put eg
> > __SYSCALL_DEFINE0 in front of the function name?  That would be considered
> > to be an attribute and then you could put __SYSCALL_DEFINE0 as an
> > attribute name in your semantic patch.
>
> sorry for having to ask again. Your suggestion sounds very reasonable. But I
> couldn't figure out how to match on attributes. I guessed it would be
> something like this
>
>   @r@
>   attribute a;
>   identifier fn;
>   @@
>
>   a fn(...) { ... }
>
> But that gives a .cocci parse error:
>
>   minus: parse error:
>     File "my.cocci", line 6, column 2, charpos = 38
>     around = 'fn',
>     whole content = a fn(...) { ... }
>
> Expected, IIUC, since attribute doesn't occur in fundecl from grammar:
>
>   fundecl ::=  [fn_ctype] funinfo * funid ([PARAMSEQ(param, ε)]) { [stmt_seq]
> }
>
> How else to look for functions with attributes then?

The return type for the function is required in this case:

@r@
attribute a;
identifier fn;
types t;
@@

* t a fn(...) { ... }

julia

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

[Markus Elfring]

>> How else to look for functions with attributes then?
> The return type for the function is required in this case:
> 
> @r@
> attribute a;
> identifier fn;
> types t;
> @@
> 
> * t a fn(...) { ... }

Would a similar source code search approach become interesting
for further clarifications?

Exclude macro calls from searches for function implementations
2024-10-28
https://github.com/coccinelle/coccinelle/issues/381

Regards,
Markus

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

[Julia Lawall]

On Sat, 29 Nov 2025, Markus Elfring wrote:

> >> How else to look for functions with attributes then?
> > The return type for the function is required in this case:
> >
> > @r@
> > attribute a;
> > identifier fn;
> > types t;
> > @@
> >
> > * t a fn(...) { ... }
>
> Would a similar source code search approach become interesting
> for further clarifications?
>
> Exclude macro calls from searches for function implementations
> 2024-10-28
> https://github.com/coccinelle/coccinelle/issues/381

Coccinelle expands macros when it has them available and when it is not
able to parse the code without doing the expansion.  This is not
controllable by the user.  The only thing you can do it perhaps provide a
different definition of the macro that better corresponds to the results
you hope for (or just remove the definition of the macro entirely, which
will cause a parse failure and thus no results for the affected code).

julia

Re: [cocci] Questionable macro expansions

[Markus Elfring]

> Coccinelle expands macros when it has them available and when it is not
> able to parse the code without doing the expansion.

I find this information relevant for further clarifications.


>                                                      This is not
> controllable by the user.

I suggest to reconsider such a view in more detail.


>                            The only thing you can do it perhaps provide a
> different definition of the macro that better corresponds to the results
> you hope for (or just remove the definition of the macro entirely, which
> will cause a parse failure and thus no results for the affected code).

Will any other software design options become more attractive?

Regards,
Markus

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

[Tobias Deiminger]

Am 29.11.2025 14:51 schrieb Julia Lawall:
> On Sat, 29 Nov 2025, Tobias Deiminger wrote:
>  [...]
> The return type for the function is required in this case:
> 
> @r@
> attribute a;
> identifier fn;
> types t;
> @@
> 
> * t a fn(...) { ... }

@Julia
Thanks, almost there...

The rule with return type you suggested works when I put the expanded 
form directly in my.c

   asmlinkage unsigned long __SYSCALL_DEFINE0 mysyscall(void) { return 0; 
}

*and* additionally add '#define __SYSCALL_DEFINE0 MACROANNOTATION' to 
standard.h. Without MACROANNOTATION I would get semantic error.

But if I put the macro form to my.c (which is my original use case)

   SYSCALL_DEFINE0(mysyscall) { return 0; }

and add either only this

   #define SYSCALL_DEFINE0(func) \
         asmlinkage unsigned long __SYSCALL_DEFINE0 func(void)

, or additionally the MACROANNOTATION hint to standard.h, I always get 
parse errors, even with return type. Any ideas what's going on?


@Markus
> You might point remaining improvement possibilities out for this 
> evolving software.

Thanks also for your pointers. I've started learning about Coccinelle 
yesterday evening and think I'm not in a position to make improvement 
suggestions :D What Julia suggested would suite my case, once it works.

Tobias

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

[Julia Lawall]

On Sat, 29 Nov 2025, Tobias Deiminger wrote:

> Am 29.11.2025 14:51 schrieb Julia Lawall:
> > On Sat, 29 Nov 2025, Tobias Deiminger wrote:
> >  [...]
> > The return type for the function is required in this case:
> >
> > @r@
> > attribute a;
> > identifier fn;
> > types t;
> > @@
> >
> > * t a fn(...) { ... }
>
> @Julia
> Thanks, almost there...
>
> The rule with return type you suggested works when I put the expanded form
> directly in my.c
>
>   asmlinkage unsigned long __SYSCALL_DEFINE0 mysyscall(void) { return 0; }
>
> *and* additionally add '#define __SYSCALL_DEFINE0 MACROANNOTATION' to
> standard.h. Without MACROANNOTATION I would get semantic error.
>
> But if I put the macro form to my.c (which is my original use case)
>
>   SYSCALL_DEFINE0(mysyscall) { return 0; }
>
> and add either only this
>
>   #define SYSCALL_DEFINE0(func) \
>         asmlinkage unsigned long __SYSCALL_DEFINE0 func(void)
>
> , or additionally the MACROANNOTATION hint to standard.h, I always get parse
> errors, even with return type. Any ideas what's going on?

There is no macro expansion in the semantic patch.

julia

>
>
> @Markus
> > You might point remaining improvement possibilities out for this evolving
> > software.
>
> Thanks also for your pointers. I've started learning about Coccinelle
> yesterday evening and think I'm not in a position to make improvement
> suggestions :D What Julia suggested would suite my case, once it works.
>
> Tobias
>

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

[Markus Elfring]

>> You might point remaining improvement possibilities out for this evolving software.
> 
> Thanks also for your pointers. I've started learning about Coccinelle yesterday evening

Interesting.


> and think I'm not in a position to make improvement suggestions :D

I guess that some clarification approaches can influence also desirable adjustments.

It seems that you would like to achieve data processing according to macro applications.
Such a technical detail can affect known open issues.

Regards,
Markus

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

[Tobias Deiminger]

Unintentionally removed the list from recipients, thus resending. Sorry 
for the noise.

Am 29.11.2025 18:29 schrieb Tobias Deiminger:
> Am 29.11.2025 17:36 schrieb Julia Lawall:
>> On Sat, 29 Nov 2025, Tobias Deiminger wrote:
>> 
>>> Am 29.11.2025 16:59 schrieb Julia Lawall:
>>> > On Sat, 29 Nov 2025, Tobias Deiminger wrote:
>>> > [...]
>>> > There is no macro expansion in the semantic patch.
>>> 
>>> Sorry, that I don't understand. Here's the complete minimal example 
>>> as I
>>> understood from your earlier advice:
>>> 
>>>   // my.c
>>>   SYSCALL_DEFINE0(foo) { return 0; }
>>> 
>>>   // my.cocci
>>>   @r@
>>>   attribute a;
>>>   identifier fn;
>>>   type t;
>>>   @@
>>>   * t a fn(...) { ... }
>>> 
>>>   // standard.h
>>>   #define  asmlinkage
>>>   #define SYSCALL_DEFINE0(func) \
>>>       asmlinkage unsigned long __SYSCALL_DEFINE0 func(void)
>> 
>> There is no macro expansion in the semantic patch.  You have to write 
>> the
>> semantic patch to match the expanded function.
> 
> Yes, I believe that's exactly what I did:
> 
> 1. The semantic patch is "* t a fn(...) { ... }". It matches the
> expanded function, where return type = unsigned long, attribute =
> __SYSCALL_DEFINE0, fn = foo.
> 
>> Macro expansion only happens in the C code.
> 
> 2. The C code is 'SYSCALL_DEFINE0(foo) { return 0; }'. I assume this C
> code is expanded by spatch to the definition in standard.h to
> "unsigned long __SYSCALL_DEFINE0 foo(void)" before the semantic patch
> gets applied.
> 
> Somewhere either me or coccinelle is wrong. Very likely the former ;-)
> 
> Tobias

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

[Markus Elfring]

> Somewhere either me or coccinelle is wrong.

I got the impression that you stumble on adjustable software limitations.

Regards,
Markus

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

[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; }

----------------------------------------------

Using * was a bad idea.  You can't transform macro expanded code.

julia

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

[Markus Elfring]

> .cocci
> 
> @r@
> symbol SYSCALL_DEFINE1;
> identifier fn;
> type t;

Is this metavariable unused in the SmPL code?


> .c
> 
> SYSCALL_DEFINE1(foo,int,x) { return 0; }

How can a macro call be matched here?


> Using * was a bad idea.  You can't transform macro expanded code.

Would any more background information become relevant here?

Regards,
Markus

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

[Julia Lawall]

On Sat, 29 Nov 2025, Markus Elfring wrote:

> > .cocci
> >
> > @r@
> > symbol SYSCALL_DEFINE1;
> > identifier fn;
> > type t;
>
> Is this metavariable unused in the SmPL code?

Yes.  The declaration is not needed.

>
>
> > .c
> >
> > SYSCALL_DEFINE1(foo,int,x) { return 0; }
>
> How can a macro call be matched here?

We have already discussed extensively that it can't.  Because the code
doesn't parse without doing the expansion.

julia

>
> > Using * was a bad idea.  You can't transform macro expanded code.
>
> Would any more background information become relevant here?
>
> Regards,
> Markus
>

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

[Markus Elfring]

>>> .c
>>>
>>> SYSCALL_DEFINE1(foo,int,x) { return 0; }
>>
>> How can a macro call be matched here?
> 
> We have already discussed extensively that it can't.

There might corresponding collateral evolution become more helpful.


>                                                       Because the code
> doesn't parse without doing the expansion.

Where is the information provided that we may actually expect a macro expansion here?
(Is special pattern recognition applied eventually?)

Does such functionality usually belong to a preprocessor?

See also:
https://gitlab.inria.fr/coccinelle/coccinelle/-/blob/4c9d00ae071800cb447efaffd753f3bb2be28800/docs/manual/introduction.tex#L1-6

Regards,
Markus

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

[Tobias Deiminger]

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

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

[Julia Lawall]

On Sat, 29 Nov 2025, Tobias Deiminger wrote:

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

In general, Coccinelle does not expand macros.  So you can match them
with no problem.  The problem here is tha there is no way to parse the
code without expanding the macro.

julia

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

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

[Markus Elfring]

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

Re: [cocci] Clarification for parsing capabilities?

[Markus Elfring]

> In general, Coccinelle does not expand macros.

Are there any “special cases” to reconsider?


>                                                 So you can match them
> with no problem.

Some data processing challenges were discussed.


>                   The problem here is tha there is no way to parse the
> code without expanding the macro.

I find this view debatable.

Several developers (and code reviewers) got trained for advanced pattern recognition,
didn't they?

Regards,
Markus

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

[Tobias Deiminger]

Hi,

Am 30.11.2025 09:05 schrieb Markus Elfring:
>> 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.

I observed this while looking for standard.h modifications that avoid 
numbering 1..6 in the 12 macro variants, so that there can be 1 simple 
common rule for all 12 variants.

 From Julia's example I found by trial that macro name and first 
parameter must have same name, otherwise it wouldn't work:

   // standard.h, try either 1st or 2nd line
   #define SYSCALL_DEFINE1(func, t1, a1) int func(int SYSCALL_DEFINE1, t1 
a1)  // works
   #define SYSCALL_DEFINE1(func, t1, a1) int func(int SYSCALL_DEFINE, t1 
a1)  // doesn't work (rule adjusted, or course)

Can you explain why the 2nd doesn't work? Looks like if there was some 
conventional relation between macro name and first parameter.

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

>> But as said, I'm not in a position to make such suggestions
> 
> Please reconsider such a view once more.

So far I think Coccinelle is an amazing tool.

Macro handling maybe was a bit surprising, quoting Julia: "Coccinelle 
expands macros when it has them available and when it is not able to 
parse the code without doing the expansion". As a user I have to know if 
a macro will be expanded or not, since match patterns have to look 
different accordingly. But the exact conditions for expansion are not 
too easy to anticipate.

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

Probably :) Do you have other suggestions?

Tobias

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

[Tobias Deiminger]

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

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

[Markus Elfring]

> I observed this while looking for standard.h modifications that …

Further information can eventually become helpful from known development history.
https://gitlab.inria.fr/coccinelle/coccinelle/-/commits/4c9d00ae071800cb447efaffd753f3bb2be28800/standard.h
https://github.com/coccinelle/coccinelle/commits/master/standard.h

Program parameters can influence the usage of header files.
https://gitlab.inria.fr/coccinelle/coccinelle/-/blob/4c9d00ae071800cb447efaffd753f3bb2be28800/docs/manual/spatch_options.tex#L407-450
https://github.com/coccinelle/coccinelle/blob/4c9d00ae071800cb447efaffd753f3bb2be28800/docs/manual/spatch_options.tex#L407-L450

Comments contain hints for the handling of “bad macros”.
https://gitlab.inria.fr/coccinelle/coccinelle/-/blob/4c9d00ae071800cb447efaffd753f3bb2be28800/standard.h#L2-56
https://github.com/coccinelle/coccinelle/blob/4c9d00ae071800cb447efaffd753f3bb2be28800/standard.h#L2-L56


> So far I think Coccinelle is an amazing tool.

Yes, of course.

This software is still improvable in various ways as can be seen by some known information systems.


>> There are promising software tools available.
> 
> Probably :) Do you have other suggestions?

I came along related development ideas.
The discussion can eventually be continued accordingly.

Regards,
Markus

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

[Markus Elfring]

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

Would you find another SmPL code variant helpful?

@display@
typedef syscall_define_t;
identifier fn;
@@
 syscall_define_t
*fn(...)
 {
 ...
 }



Did you notice any hints from a test of a known program parameter?

Markus_Elfring@Sonne:…/Projekte/Coccinelle/Probe> /usr/bin/spatch --parse-cocci example_for_Tobias_Deiminger-20251201.cocci
…
Grep query
syscall_define_t


> is that spatch filters .c files early by raw text search for "syscall_define_t", before it actually processes patterns.

See also once more:
coccigrep
https://gitlab.inria.fr/coccinelle/coccinelle/-/blob/4c9d00ae071800cb447efaffd753f3bb2be28800/docs/manual/spatch_options.tex#L235-245
https://github.com/coccinelle/coccinelle/blob/4c9d00ae071800cb447efaffd753f3bb2be28800/docs/manual/spatch_options.tex#L235-L245

Regards,
Markus

Re: [cocci] Searching for system call implementations with SmPL?

[Markus Elfring]

> But I really want to search all syscalls by the conventional macro names, i.e. search for SYSCALL_DEFINE[0-6]+. How to do that?

My pattern recognition needed a while to take another software design approach into account.
https://gitlab.inria.fr/coccinelle/coccinelle/-/blob/4c9d00ae071800cb447efaffd753f3bb2be28800/docs/manual/cocci_syntax.tex#L480-482

Corresponding SmPL script example:
@display disable braces0@
iterator name SYSCALL_DEFINE0;
@@
*SYSCALL_DEFINE0(...)
 {
 ...
 }


Questionable test result (according to the software combination “Coccinelle 1.3.1”):
Markus_Elfring@Sonne:…/Projekte/Linux/next-analyses> /usr/bin/spatch --macro-file-builtins …/Projekte/Coccinelle/Probe/my_empty_header_file.h arch/alpha/kernel/osf_sys.c …/Projekte/Coccinelle/Probe/suggestion_for_Tobias_Deiminger-20251202.cocci
…
[no diff output]


How will the clarification be continued for more desirable software behaviour?

Regards,
Markus

Re: [cocci] Searching for system call implementations?

[Markus Elfring]

>> There are promising software tools available.
> 
> Probably 🙂 Do you have other suggestions?

Would you become interested to check if your use case would be supported also
by the programming interface “CodeQL”?
https://codeql.github.com/docs/codeql-language-guides/codeql-for-cpp/

Regards,
Markus