Re: [cocci] Searching for duplicate exception handling code with SmPL?

Am 16.06.26 um 09:19 schrieb Julia Lawall:
>=20
>=20
> On Tue, 16 Jun 2026, Markus Elfring wrote:
>=20
>>>>> Is such a number suspicious together with the information =E2=80=9C9=
620 files match=E2=80=9D?
>>>>
>>>> I adjusted the implementation of the function =E2=80=9Cdisplay_data=
=E2=80=9D another bit
>>>> so that a questionable condition can be checked and displayed directl=
y.
>> =E2=80=A6
>>>> Markus_Elfring@Sonne:=E2=80=A6/Projekte/Bau/Linux/scripts/Coccinelle>=
 rg 'hit' list_selected_duplicate_statements_in_if_branches4-20260612.txt =
| wc -l
>>>> 254
>>>>
>>>>
>>>> Such a number looks more promising for possible update candidates,
>>>> doesn't it?
>>>
>>> I don't know what your semantic patch does,
>>
>> Why did you not forward original background information to the mailing =
list
>> for Coccinelle so far?
>>
>> 2026-06-14
>> https://lore.kernel.org/cocci/bd197670-dc1f-5c82-2bf-9e6316b29da8@inria=
.fr/
>> https://sympa.inria.fr/sympa/arc/cocci/2026-06/msg00010.html
>>
>>
>>>                                             so I don't know whether th=
e
>>> result is useful or not.
>> So I hope also again that the following SmPL script variant can influen=
ce development ideas
>> in desirable directions.
>>
>>
>> @initialize:python@
>> @@
>> import sys
>> delimiter =3D "|"
>>
>> def display_data(fun, source1, source2, x, y):
>>     sys.stdout.write(delimiter.join(("info", fun, x, y))
>>                         + "\n")
>>     place1 =3D source1[0]
>>     place2 =3D source2[0]
>> #    if place1 =3D=3D place2:
>>     if (place1.line =3D=3D place2.line) and (place1.column =3D=3D place=
2.column):
>>        sys.stdout.write(delimiter.join(("error",
>>                                         "same position",
>>                                         place1.file,
>>                                         place1.line,
>>                                         str(int(place1.column) + 1)))
>>                         + "\n")
>>
>>     else:
>>        sys.stdout.write(delimiter.join(("hit",
>>                                         place1.file,
>>                                         place1.line,
>>                                         str(int(place1.column) + 1),
>>                                         place2.line,
>>                                         str(int(place2.column) + 1)))
>>                         + "\n")
>>
>> @searching exists@
>> expression e, x;
>> identifier item, rc, work;
>> position p1, p2;
>> type t;
>> @@
>>  t work(...)
>>  {
>>  ... when any
>>  if (...)
>>  {
>>  ... when !=3D rc =3D e
>>      when !=3D item =3D x
>>  kfree@p1(item);
>>  return rc;
>>  }
>>  ... when any
>>  if (...)
>>  {
>>  ... when !=3D rc =3D e
>>      when !=3D item =3D x
>>  kfree@p2(item);
>>  return rc;
>>  }
>>  ... when any
>>  }
>=20
> So why do you think that the number of relevant files diminshed?

I find that further development considerations can become more interesting
also according to the presented checks for source code positions.


> Coccinelle informs you of what tokens it has considered, but I don't thi=
nk
> you included that.

Which data would you miss at the moment?


> Furthermore, it seems strange that you declare rc to be an identifier.

I obviously restricted the source code approach so far.


> -ENOMEM, for example, is not an identifier.  It is an expression.

This is fine.

The detection of duplicate error code returns can eventually be achieved
with another SmPL script variant.


> And you still have no checks for gotos,

This is intended so far.


>                                         so you will still get cases wher=
e
> both kfrees are on the same line.

I hope also that further case distinctions will become helpful for corresp=
onding clarifications.



>                                    Another approach is to just adjust yo=
ur
> python code to discard such cases.  I see that you do that already.

Interesting =E2=80=A6


> But why not just ignore such results instead of complaining about them?

I see opportunities for corresponding data processing improvements.


> Is there really nothing like printf in python?

There are constraints to consider for the application of such programming =
interfaces.
https://docs.python.org/3/library/functions.html#print


> sys.stdout.write(delimiter.join looks very primitive.

See also:
https://docs.python.org/3/library/sys.html#sys.stdout

Regards,
Markus