[cocci] Reconsidering application of selected SmPL isomorphisms

[cocci] Reconsidering application of selected SmPL isomorphisms

[Markus Elfring]

Hello,

I would like to clarify software development consequences also for
a simple script variant for the semantic patch language (like the following).


@show_questionable_checks@
expression e1, e2;
statement s1, s2;
@@
 if
 (
*!(e1 || e2)
 )
    s1
 else
    s2


Questionable test result:
Markus_Elfring@Sonne:/home/altes_Heim2/elfring/Projekte/Coccinelle/janitor> spatch --parse-cocci show_questionable_OR_checks2.cocci
…
(

(

(
if (*!*(*e1 *|| *e2*))
|
if (*!*e1 *|| *e2)
)s1 else s2
|
…


I would interpret such data display in the way that the isomorphism “paren”
was applied here.
https://gitlab.inria.fr/coccinelle/coccinelle/-/blob/04f71e76b0857ca12ec7207b26368df78d2b57d4/standard.iso#L389

I find the shown SmPL code transformation inappropriate at this place.
Would we like to apply De Morgan's laws instead?
https://en.wikipedia.org/wiki/De_Morgan%27s_laws

Would we like to reconsider the application of the isomorphism for the switching
of if/else branches accordingly?

Regards,
Markus

Re: [cocci] Reconsidering application of selected SmPL isomorphisms

[Julia Lawall]

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



On Mon, 25 Nov 2024, Markus Elfring wrote:

> Hello,
>
> I would like to clarify software development consequences also for
> a simple script variant for the semantic patch language (like the following).
>
>
> @show_questionable_checks@
> expression e1, e2;
> statement s1, s2;
> @@
>  if
>  (
> *!(e1 || e2)
>  )
>     s1
>  else
>     s2
>
>
> Questionable test result:
> Markus_Elfring@Sonne:/home/altes_Heim2/elfring/Projekte/Coccinelle/janitor> spatch --parse-cocci show_questionable_OR_checks2.cocci
> …
> (
>
> (
>
> (
> if (*!*(*e1 *|| *e2*))
> |
> if (*!*e1 *|| *e2)
> )s1 else s2
> |
> …
>
>
> I would interpret such data display in the way that the isomorphism “paren”
> was applied here.
> https://gitlab.inria.fr/coccinelle/coccinelle/-/blob/04f71e76b0857ca12ec7207b26368df78d2b57d4/standard.iso#L389
>
> I find the shown SmPL code transformation inappropriate at this place.
> Would we like to apply De Morgan's laws instead?
> https://en.wikipedia.org/wiki/De_Morgan%27s_laws
>
> Would we like to reconsider the application of the isomorphism for the switching
> of if/else branches accordingly?

Indeed, it looks wrong.

Thanks for the report.

julia

Re: [cocci] Reconsidering application of selected SmPL isomorphisms

[Julia Lawall]

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



On Mon, 25 Nov 2024, Markus Elfring wrote:

> Hello,
>
> I would like to clarify software development consequences also for
> a simple script variant for the semantic patch language (like the following).

The generated code indeed does not look ideal.  But it won't cause any
wrong matches.  The isomorphisms are applied on the ASTs, not on the soure
code.  So there will be a tree with a ! at the root and a || as the
argument that will not match any possible source code.

Maybe it would be better to add isomorphisms for the de Morgan laws rather
than adding some hacks into the generic isomorphism transformation to take
this issue into account.

julia

>
>
> @show_questionable_checks@
> expression e1, e2;
> statement s1, s2;
> @@
>  if
>  (
> *!(e1 || e2)
>  )
>     s1
>  else
>     s2
>
>
> Questionable test result:
> Markus_Elfring@Sonne:/home/altes_Heim2/elfring/Projekte/Coccinelle/janitor> spatch --parse-cocci show_questionable_OR_checks2.cocci
> …
> (
>
> (
>
> (
> if (*!*(*e1 *|| *e2*))
> |
> if (*!*e1 *|| *e2)
> )s1 else s2
> |
> …
>
>
> I would interpret such data display in the way that the isomorphism “paren”
> was applied here.
> https://gitlab.inria.fr/coccinelle/coccinelle/-/blob/04f71e76b0857ca12ec7207b26368df78d2b57d4/standard.iso#L389
>
> I find the shown SmPL code transformation inappropriate at this place.
> Would we like to apply De Morgan's laws instead?
> https://en.wikipedia.org/wiki/De_Morgan%27s_laws
>
> Would we like to reconsider the application of the isomorphism for the switching
> of if/else branches accordingly?
>
> Regards,
> Markus
>

Re: [cocci] Reconsidering application of selected SmPL isomorphisms

[Markus Elfring]

> The generated code indeed does not look ideal.  But it won't cause any
> wrong matches.

I got the impression that I would need to disable the isomorphism “paren”
for the desired use case.



>                 The isomorphisms are applied on the ASTs, not on the soure code.

I remember other description approaches.
Are isomorphisms usually mapped to SmPL disjunctions?


>        So there will be a tree with a ! at the root and a || as the
> argument that will not match any possible source code.
>
> Maybe it would be better to add isomorphisms for the de Morgan laws rather
> than adding some hacks into the generic isomorphism transformation to take
> this issue into account.

I am looking for further software extensions.

* I would occasionally like to restrict the source code search to pointer expressions.

* Specifying a varying (or even unlimited) number of items for discussed boolean operators


Regards,
Markus

Re: [cocci] Reconsidering application of selected SmPL isomorphisms

[Julia Lawall]

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



On Mon, 25 Nov 2024, Markus Elfring wrote:

> > The generated code indeed does not look ideal.  But it won't cause any
> > wrong matches.
>
> I got the impression that I would need to disable the isomorphism “paren”
> for the desired use case.
>
>
>
> >                 The isomorphisms are applied on the ASTs, not on the soure code.
>
> I remember other description approaches.
> Are isomorphisms usually mapped to SmPL disjunctions?

Yes.  That is orthogonal to what I am saying.  My point is that the way
that you see the code printed does not correspond to the actual internal
parse tree.  The internal parse tree is the same as the original one, but
with the parentheses removed.  There is no C source code that generates
such a parse tree, so the generated disjunction branch will not match
anything.

Some effort is made to accomodate !, but only when the isomorphism
contains ! applied to a metavariable, not for ! applied to more
complicated things.

>
>
> >        So there will be a tree with a ! at the root and a || as the
> > argument that will not match any possible source code.
> >
> > Maybe it would be better to add isomorphisms for the de Morgan laws rather
> > than adding some hacks into the generic isomorphism transformation to take
> > this issue into account.
>
> I am looking for further software extensions.
>
> * I would occasionally like to restrict the source code search to pointer expressions.

expression *e;

> * Specifying a varying (or even unlimited) number of items for discussed boolean operators

  e1 || ...

julia

Re: [cocci] Reconsidering application of selected SmPL isomorphisms

[Markus Elfring]

>> * Specifying a varying (or even unlimited) number of items for discussed boolean operators
>
>   e1 || ...
* Does such SmPL code indicate that subsequent expression parts can be optional?

* How should the shown SmPL ellipsis be restricted according to such an operator?


Regards,
Markus

Re: [cocci] Reconsidering application of selected SmPL isomorphisms

[Julia Lawall]

On Mon, 25 Nov 2024, Markus Elfring wrote:

> >> * Specifying a varying (or even unlimited) number of items for discussed boolean operators
> >
> >   e1 || ...
> * Does such SmPL code indicate that subsequent expression parts can be optional?

Yes.

>
> * How should the shown SmPL ellipsis be restricted according to such an operator?

I think there is no possibility of restriction.  You can put previous
disjunctions with the patterns you don't like.

julia

Re: [cocci] Advanced handling of logical operator chains (with SmPL)?

[Markus Elfring]

>>>> * Specifying a varying (or even unlimited) number of items for discussed boolean operators
>>>
>>>   e1 || ...
>> * Does such SmPL code indicate that subsequent expression parts can be optional?
>
> Yes.

I am looking for ways to express by the means of the semantic patch language
that such a detailed expression should contain at least two operands
which would all be connected with a logical OR.

Regards,
Markus

Re: [cocci] Advanced handling of logical operator chains (with SmPL)?

[Julia Lawall]

On Mon, 25 Nov 2024, Markus Elfring wrote:

> >>>> * Specifying a varying (or even unlimited) number of items for discussed boolean operators
> >>>
> >>>   e1 || ...
> >> * Does such SmPL code indicate that subsequent expression parts can be optional?
> >
> > Yes.
>
> I am looking for ways to express by the means of the semantic patch language
> that such a detailed expression should contain at least two operands
> which would all be connected with a logical OR.

Maybe you just want to disable the isomorphism?

julia

Re: [cocci] Advanced handling of logical operator chains (with SmPL)?

[Markus Elfring]

>> I am looking for ways to express by the means of the semantic patch language
>> that such a detailed expression should contain at least two operands
>> which would all be connected with a logical OR.
>
> Maybe you just want to disable the isomorphism?
An isomorphism deactivation does probably not influence the handling of required
expression parts (>= 2 operands).

Regards,
Markus

Re: [cocci] Data processing challenges for pointer expressions

[Markus Elfring]

>> * I would occasionally like to restrict the source code search to pointer expressions.
>
> expression *e;
There are further data processing challenges to consider with the determination
of involved pointer types, aren't there?

Regards,
Markus

Re: [cocci] Data processing challenges for pointer expressions

[Julia Lawall]

On Mon, 25 Nov 2024, Markus Elfring wrote:

> >> * I would occasionally like to restrict the source code search to pointer expressions.
> >
> > expression *e;
> There are further data processing challenges to consider with the determination
> of involved pointer types, aren't there?

Could you please explain what you mean?

You can use options like --all-includes or --recursive-includes to get
more information from header files if it is needed to obtain the type
information.

But I have no idea what is a "data processing challenge".

julia

Re: [cocci] Data processing challenges for pointer expressions

[Markus Elfring]

> You can use options like --all-includes or --recursive-includes to get
> more information from header files if it is needed to obtain the type
> information.
>
> But I have no idea what is a "data processing challenge".
The mentioned program parameters trigger some “side effects”.

Example for corresponding development considerations:
How to fix a stack overflow?
2014-10-20
https://github.com/coccinelle/coccinelle/issues/30

Regards,
Markus

Re: [cocci] Data processing challenges for source code analyses

[Markus Elfring]

> You can use options like --all-includes or --recursive-includes to get
> more information from header files if it is needed to obtain the type
> information.
>
> But I have no idea what is a "data processing challenge".
Another example:
Markus_Elfring@Sonne:…/Projekte/Linux/next-analyses> ls -sk drivers/gpu/drm/amd/include/asic_reg/dcn/dcn_3_2_0_sh_mask.h
23392 drivers/gpu/drm/amd/include/asic_reg/dcn/dcn_3_2_0_sh_mask.h


* Under which circumstances will software development interests grow
  also for the amount of preprocessing code in such header files?

* Would you like to take another look at any size statistics for source files?


Regards,
Markus