[cocci] bug: Matching a specific declarer actually matches any declarer

[cocci] bug: Matching a specific declarer actually matches any declarer

[Tobias Deiminger]

Hi,

to reproduce the issue, try mutex2.cocci from coccinellery [1] with the 
code below.

Expectation: Only spin_lock calls where the variable was declared with 
DEFINE_MUTEX() are patched.

Actual: The declarer name seems to be ignored. All spin_lock calls are 
patched, regardless of the declarer name

// mutex2.c
DEFINE_MUTEX(my_mutex);
OTHER_DECLARER(other_mutex);

void main() {
     // this should be changed, declarer was DEFINE_MUTEX
     spin_lock(&my_mutex);

     // this should not be changed, declarer was OTHER_DECLARER
     spin_lock(&other_mutex)
}

// mutex2.cocci
@def@
declarer DEFINE_MUTEX;
identifier m;
@@

DEFINE_MUTEX(m);

@@
identifier def.m;
@@

(
- spin_lock(&m)
+ mutex_lock(&m)
|
- spin_unlock(&m)
+ mutex_unlock(&m)
)

The unexpected result:

$ spatch --sp-file mutex2.cocci mutex2.c
init_defs_builtins: /usr/lib/coccinelle/standard.h
HANDLING: mutex2.c
SPECIAL NAMES: adding OTHER_DECLARER as a declarer
diff =
--- mutex2.c
+++ /tmp/cocci-output-71243-6eaa4e-my.c
@@ -3,8 +3,8 @@ OTHER_DECLARER(other_mutex);

  void main() {
      // this should be changed, declarer was DEFINE_MUTEX
-    spin_lock(&my_mutex);
+    mutex_lock(&my_mutex);

      // this should not be changed, declarer was OTHER_DECLARER
-    spin_lock(&other_mutex)
+    mutex_lock(&other_mutex)
  }


Could you confirm, and maybe suggest a workaround? I used the 
coccinellery example as reproducer because it's public, but actually 
stumbled upon the issue in a simpler case: I searched for all 
occurrences of DEVICE_ATTR_RO(attr) in the Linux kernel, but actually 
found every place where *any* macro was used to declare something.

Cheers
Tobias

PS: I'm using spatch 1.3 from Debian trixie.

[1] 
https://github.com/coccinelle/coccinellery/blob/master/cris/mutex2.cocci

Re: [cocci] bug: Matching a specific declarer actually matches any declarer

[Julia Lawall]

On Mon, 1 Dec 2025, Tobias Deiminger wrote:

> Hi,
>
> to reproduce the issue, try mutex2.cocci from coccinellery [1] with the code
> below.
>
> Expectation: Only spin_lock calls where the variable was declared with
> DEFINE_MUTEX() are patched.
>
> Actual: The declarer name seems to be ignored. All spin_lock calls are
> patched, regardless of the declarer name
>
> // mutex2.c
> DEFINE_MUTEX(my_mutex);
> OTHER_DECLARER(other_mutex);
>
> void main() {
>     // this should be changed, declarer was DEFINE_MUTEX
>     spin_lock(&my_mutex);
>
>     // this should not be changed, declarer was OTHER_DECLARER
>     spin_lock(&other_mutex)
> }
>
> // mutex2.cocci
> @def@
> declarer DEFINE_MUTEX;

This should be declarer name, not declarer.  Declarer matches any declarer
name.

julia

> identifier m;
> @@
>
> DEFINE_MUTEX(m);
>
> @@
> identifier def.m;
> @@
>
> (
> - spin_lock(&m)
> + mutex_lock(&m)
> |
> - spin_unlock(&m)
> + mutex_unlock(&m)
> )
>
> The unexpected result:
>
> $ spatch --sp-file mutex2.cocci mutex2.c
> init_defs_builtins: /usr/lib/coccinelle/standard.h
> HANDLING: mutex2.c
> SPECIAL NAMES: adding OTHER_DECLARER as a declarer
> diff =
> --- mutex2.c
> +++ /tmp/cocci-output-71243-6eaa4e-my.c
> @@ -3,8 +3,8 @@ OTHER_DECLARER(other_mutex);
>
>  void main() {
>      // this should be changed, declarer was DEFINE_MUTEX
> -    spin_lock(&my_mutex);
> +    mutex_lock(&my_mutex);
>
>      // this should not be changed, declarer was OTHER_DECLARER
> -    spin_lock(&other_mutex)
> +    mutex_lock(&other_mutex)
>  }
>
>
> Could you confirm, and maybe suggest a workaround? I used the coccinellery
> example as reproducer because it's public, but actually stumbled upon the
> issue in a simpler case: I searched for all occurrences of
> DEVICE_ATTR_RO(attr) in the Linux kernel, but actually found every place where
> *any* macro was used to declare something.
>
> Cheers
> Tobias
>
> PS: I'm using spatch 1.3 from Debian trixie.
>
> [1] https://github.com/coccinelle/coccinellery/blob/master/cris/mutex2.cocci
>

Re: [cocci] bug: Matching a specific declarer actually matches any declarer

[Tobias Deiminger]

Am 01.12.2025 16:35 schrieb Julia Lawall:
> On Mon, 1 Dec 2025, Tobias Deiminger wrote:
[...]
>> // mutex2.cocci
>> @def@
>> declarer DEFINE_MUTEX;
> 
> This should be declarer name, not declarer.  Declarer matches any 
> declarer
> name.

That works => not a bug.

Thanks a lot.

Tobias

Re: [cocci] Matching a specific declarer?

[Markus Elfring]

> Could you confirm, and maybe suggest a workaround?

Julia has pointed another distinction out a moment ago.
https://gitlab.inria.fr/coccinelle/coccinelle/-/blob/4c9d00ae071800cb447efaffd753f3bb2be28800/docs/manual/cocci_syntax.tex#L473-478


> I used the coccinellery example as reproducer because it's public,

Thanks for another look at this information source.


> but actually stumbled upon the issue in a simpler case: I searched for all occurrences of DEVICE_ATTR_RO(attr) in the Linux kernel,

Will it become more interesting to clarify your own source code search approaches?


> but actually found every place where *any* macro was used to declare something.

Would you be looking for any better documentation also in this application area?


> PS: I'm using spatch 1.3 from Debian trixie.

It might become also interesting with which delay subsequent software tool revisions
will be usable.

Regards,
Markus

Re: [cocci] Matching a specific declarer?

[Tobias Deiminger]

Am 01.12.2025 17:00 schrieb Markus Elfring:
> [...]
>> but actually stumbled upon the issue in a simpler case: I searched for 
>> all occurrences of DEVICE_ATTR_RO(attr) in the Linux kernel,
> 
> Will it become more interesting to clarify your own source code search
> approaches?

Sorry, not sure I understand the question. Is there anything I should 
do, or should avoid to do, or tell about?

If I manage to compile meaningful results until next week, I maybe add 
some words about the code search approach to my LPC talk:
https://lpc.events/event/19/contributions/2198/

>> but actually found every place where *any* macro was used to declare 
>> something.
> 
> Would you be looking for any better documentation also in this 
> application area?

You mean better Coccinelle documentation? I think it's ok. This list is 
very responsive and helpful, that more than compensates for gaps in 
documentation, if any. Also my use case is in the niche of a niche, so 
really not demanding anything.

>> PS: I'm using spatch 1.3 from Debian trixie.
> 
> It might become also interesting with which delay subsequent software
> tool revisions
> will be usable.

Which revisions of which tool do you mean?

Tobias

Re: [cocci] Matching a specific declarer?

[Markus Elfring]

>>> but actually stumbled upon the issue in a simpler case: I searched for all occurrences of DEVICE_ATTR_RO(attr) in the Linux kernel,
>>
>> Will it become more interesting to clarify your own source code search approaches?
> 
> Sorry, not sure I understand the question. Is there anything I should do, or should avoid to do, or tell about?

It depends …

It seems that an information source like “Coccinellery” can trigger special questions
for more desirable software behaviour.
Further inspirations are generally possible.


> If I manage to compile meaningful results until next week, I maybe add some words about the code search approach to my LPC talk:
> https://lpc.events/event/19/contributions/2198/

I am curious how experience exchange will evolve also by the means of subsequent conferences.


> You mean better Coccinelle documentation?

I still hope that something can be adjusted here.


> I think it's ok. This list is very responsive and helpful, that more than compensates for gaps in documentation, if any.

Thanks for such a positive feedback.


> Also my use case is in the niche of a niche, so really not demanding anything.

But it seems that your development ideas can push existing limits.


>> It might become also interesting with which delay subsequent software
>> tool revisions will be usable.
> 
> Which revisions of which tool do you mean?

Did you notice the announcement “Coccinelle 1.3.1 release” (for example)?
https://lore.kernel.org/cocci/2cd30151-1ac8-4e67-8ecc-962326931d99@inria.fr/
https://sympa.inria.fr/sympa/arc/cocci/2025-11/msg00057.html

Regards,
Markus