[cocci] Transforming source code according to the usage of a predicate

[cocci] Transforming source code according to the usage of a predicate

[Markus Elfring]

Hello,

I noticed a suggestion in another issue tracker.

2022-11-25
Detect if/else branches that only differ by condition variable
https://trac.cppcheck.net/ticket/11402


I tried to construct a script variant for the semantic patch language
(software combination “Coccinelle 1.1.1”) accordingly.


@replacement disable neg_if, drop_else@
bool active;
expression call;
@@
 <+...
(
-if (active) {
    call(active, ...);
-} else {
-   call(!active, ...);
-}
|
-if (active) {
    call(..., active);
-} else {
-   call(..., !active);
-}
)
 ...+>



I hoped that an isomorphism can take care of special compound statements.
https://gitlab.inria.fr/coccinelle/coccinelle/-/blob/87350d742df39d847b15af39865329c2fe23460d/standard.iso#L523

Unfortunately, I stumbled on information like the following.


Markus_Elfring@Sonne:…/Projekte/Coccinelle/Probe> spatch --parse-cocci cppcheck-11402-suggestion2-20221225.cocci
…
warning: iso braces4 does not match the code below on line 7
…


Will the chances grow to simplify and improve the shown SmPL code any further?

Regards,
Markus

Re: [cocci] Transforming source code according to the usage of a predicate

[Julia Lawall]

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



On Sun, 25 Dec 2022, Markus Elfring wrote:

> Hello,
>
> I noticed a suggestion in another issue tracker.
>
> 2022-11-25
> Detect if/else branches that only differ by condition variable
> https://trac.cppcheck.net/ticket/11402
>
>
> I tried to construct a script variant for the semantic patch language
> (software combination “Coccinelle 1.1.1”) accordingly.
>
>
> @replacement disable neg_if, drop_else@
> bool active;
> expression call;
> @@
>  <+...
> (
> -if (active) {
>     call(active, ...);
> -} else {
> -   call(!active, ...);
> -}
> |
> -if (active) {
>     call(..., active);
> -} else {
> -   call(..., !active);
> -}
> )
>  ...+>
>
>
>
> I hoped that an isomorphism can take care of special compound statements.
> https://gitlab.inria.fr/coccinelle/coccinelle/-/blob/87350d742df39d847b15af39865329c2fe23460d/standard.iso#L523
>
> Unfortunately, I stumbled on information like the following.
>
>
> Markus_Elfring@Sonne:…/Projekte/Coccinelle/Probe> spatch --parse-cocci cppcheck-11402-suggestion2-20221225.cocci
> …
> warning: iso braces4 does not match the code below on line 7
> …
>
>
> Will the chances grow to simplify and improve the shown SmPL code any further?

Unlikely.

Your semantic patch also seems strange.  Don't you want something like

expression list e1,e2;

and then call(e1,active,e2)

julia

>
> Regards,
> Markus
>
>

Re: [cocci] Transforming source code according to the usage of a predicate

[Markus Elfring]

>> Markus_Elfring@Sonne:…/Projekte/Coccinelle/Probe> spatch --parse-cocci cppcheck-11402-suggestion2-20221225.cocci
>> …
>> warning: iso braces4 does not match the code below on line 7
>> …
>>
>>
>> Will the chances grow to simplify and improve the shown SmPL code any further?
> Unlikely.

We come along different views for corresponding development possibilities.



> Your semantic patch also seems strange.

I hope that the presented SmPL script version can help to clarify involved
implementation details.

Thus I specified that a boolean value can be passed as the first
or last parameter.



> Don't you want something like
>
> expression list e1,e2;
>
> and then call(e1,active,e2)


Does the specification of this metavariable type indicate the expectation
that the applied metavariables will receive contents?

The boolean value can occasionally occur also between other parameters.


Branch (or compound) isomorphisms are supported to some degree.
https://gitlab.inria.fr/coccinelle/coccinelle/-/blob/87350d742df39d847b15af39865329c2fe23460d/standard.iso#L492

It seems that I am looking also for further software evolution according to
the comment “maybe a cocci patch should require something that looks like
what is on the left above to occur in a if or while”.

Regards,
Markus

Re: [cocci] Transforming source code according to the usage of a predicate

[Julia Lawall]

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

> > Don't you want something like
> >
> > expression list e1,e2;
> >
> > and then call(e1,active,e2)
>
>
> Does the specification of this metavariable type indicate the expectation
> that the applied metavariables will receive contents?

No, it should not.  Lists can be empty.

julia

> The boolean value can occasionally occur also between other parameters.
>
>
> Branch (or compound) isomorphisms are supported to some degree.
> https://gitlab.inria.fr/coccinelle/coccinelle/-/blob/87350d742df39d847b15af39865329c2fe23460d/standard.iso#L492
>
> It seems that I am looking also for further software evolution according to
> the comment “maybe a cocci patch should require something that looks like
> what is on the left above to occur in a if or while”.
>
> Regards,
> Markus
>
>

Re: [cocci] Transforming source code according to the usage of a predicate

[Markus Elfring]

>>> Don't you want something like
>>>
>>> expression list e1,e2;
>>>
>>> and then call(e1,active,e2)
>> Does the specification of this metavariable type indicate the expectation
>> that the applied metavariables will receive contents?
> No, it should not.  Lists can be empty.

Will the distinction if list metavariables may be empty (or not)
occasionally become more relevant?

Will the chances grow to extend the software documentation accordingly?
https://gitlab.inria.fr/coccinelle/coccinelle/-/blob/87350d742df39d847b15af39865329c2fe23460d/docs/manual/cocci_syntax.tex#L425

Regards,
Markus

Re: [cocci] Transforming source code according to the usage of a predicate

[Markus Elfring]

>> Does the specification of this metavariable type indicate the expectation
>> that the applied metavariables will receive contents?
> No, it should not.  Lists can be empty.

I checked another SmPL script variant once more.

@replacement disable neg_if, drop_else@
bool active;
expression call;
expression list el1, el2;
@@
 <+...
-if (active) {
    call(el1, active, el2);
-} else {
-   call(el1, !active, el2);
-}
 ...+>


Markus_Elfring@Sonne:…/Projekte/Coccinelle/Probe> spatch --parse-cocci cppcheck-11402-suggestion3-20221226.cocci
…
@replacement@
bool  active;

Would you like to reconsider the detail why two words are delimited by
two space characters at this place?


…
@@

<+...

  -if -(-active-) -{
    call(el1, active, el2);
  -} -else
  (
  -{
    -call-(-el1-, -!-active-, -el2-)-;
  -}
  |
  -call-(-el1-, -!-active-, -el2-)-;
  )
...+>

I got the impression from such an SmPL representation that a compound isomorphism
was applied as expected for the discussed use case.
Can subsequent messages be confusing then?


warning: iso braces4 does not match the code below on line 7
{
  call(el1, bool active/* bool  */,

Why was a comment added for such a parameter?


el2);
}

the following code matched is not uniformly minus or context,
or contains a disjunction:
Stm:
{
  call(el1, bool active/* bool  */,
el2);
}

I would interpret the shown code fragment in the way that it does not contain
elements which were mentioned by the message.
How do such details fit together?

Regards,
Markus

Re: [cocci] Another extension for the software documentation

[Markus Elfring]

> Lists can be empty.


Are you going to add this information to the SmPL manual?

https://gitlab.inria.fr/coccinelle/coccinelle/-/blob/87350d742df39d847b15af39865329c2fe23460d/docs/manual/cocci_syntax.tex#L315

Regards,
Markus

Re: [cocci] Another extension for the software documentation

[Julia Lawall]

On Tue, 27 Dec 2022, Markus Elfring wrote:

> > Lists can be empty.
>
>
> Are you going to add this information to the SmPL manual?
>
> https://gitlab.inria.fr/coccinelle/coccinelle/-/blob/87350d742df39d847b15af39865329c2fe23460d/docs/manual/cocci_syntax.tex#L315

OK

Re: [cocci] Another extension for the software documentation

[Markus Elfring]

>>> Lists can be empty.
>>
>> Are you going to add this information to the SmPL manual?
>>
>> https://gitlab.inria.fr/coccinelle/coccinelle/-/blob/87350d742df39d847b15af39865329c2fe23460d/docs/manual/cocci_syntax.tex#L315
> OK


Thanks for your tiny documentation adjustment.

make clear that list metavariables can match nothing
https://gitlab.inria.fr/coccinelle/coccinelle/-/commit/b9603af4eca7f4c771d57a3861855332e9bb1c4c


Can it occasionally be required that such list metavariables should match
one item at least?

Regards,
Markus

Re: [cocci] Another extension for the software documentation

[Julia Lawall]

On Tue, 27 Dec 2022, Markus Elfring wrote:

> >>> Lists can be empty.
> >>
> >> Are you going to add this information to the SmPL manual?
> >>
> >> https://gitlab.inria.fr/coccinelle/coccinelle/-/blob/87350d742df39d847b15af39865329c2fe23460d/docs/manual/cocci_syntax.tex#L315
> > OK
>
>
> Thanks for your tiny documentation adjustment.
>
> make clear that list metavariables can match nothing
> https://gitlab.inria.fr/coccinelle/coccinelle/-/commit/b9603af4eca7f4c771d57a3861855332e9bb1c4c
>
>
> Can it occasionally be required that such list metavariables should match
> one item at least?

When you have a list metavariable, you can access the size, and then you
can use some script code to ensure that the size is greater than 0.

julia

Re: [cocci] Another extension for the software documentation

[Markus Elfring]

>> Can it occasionally be required that such list metavariables should match
>> one item at least?
> When you have a list metavariable, you can access the size, and then you
> can use some script code to ensure that the size is greater than 0.


I would occasionally prefer to restrict the minimum and/or maximum number
of items by other means in a more direct way.

Regards,
Markus

Re: [cocci] Working with filled data structures

[Markus Elfring]

>> Does the specification of this metavariable type indicate the expectation
>> that the applied metavariables will receive contents?
> No, it should not.  Lists can be empty.

How would you call a related data structure which must not be empty?

Is there a need to express special constraints?

Regards,
Markus

Re: [cocci] Working with filled data structures

[Julia Lawall]

On Sat, 7 Jan 2023, Markus Elfring wrote:

> >> Does the specification of this metavariable type indicate the expectation
> >> that the applied metavariables will receive contents?
> > No, it should not.  Lists can be empty.
>
> How would you call a related data structure which must not be empty?
>
> Is there a need to express special constraints?

If you want to be sure that the list is not empty, you can either use
python to put a constraint on the length or make a pattern that contains
one element followed by a list.

julia

Re: [cocci] Working with filled data structures

[Markus Elfring]

> If you want to be sure that the list is not empty, you can either use
> python to put a constraint on the length


Would this data processing approach need an extra SmPL rule for
a supported scripting language?


> or make a pattern that contains one element followed by a list.

Would this design variant need pairs of metavariables?


How do you think about the possibility to add a corresponding metavariable
type like “array”?

Regards,
Markus

Re: [cocci] Working with filled data structures

[Julia Lawall]

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



On Sat, 7 Jan 2023, Markus Elfring wrote:

> > If you want to be sure that the list is not empty, you can either use
> > python to put a constraint on the length
>
>
> Would this data processing approach need an extra SmPL rule for
> a supported scripting language?

No, eg, expression list[n] es : script:ocaml(n) { n > 0 };

>
>
> > or make a pattern that contains one element followed by a list.
>
> Would this design variant need pairs of metavariables?
>
>
> How do you think about the possibility to add a corresponding metavariable
> type like “array”?

Array does not suggest to me anything like what you are asking for.

julia

> Regards,
> Markus
>

Re: [cocci] Working with filled data structures

[Markus Elfring]

>>> or make a pattern that contains one element followed by a list.
>> Would this design variant need pairs of metavariables?
>>
>>
>> How do you think about the possibility to add a corresponding metavariable
>> type like “array”?
> Array does not suggest to me anything like what you are asking for.

Which data type name would you find more appropriate for the ordered storage
of a varying number of items?

Regards,
Markus

Re: [cocci] Working with filled data structures

[Julia Lawall]

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



On Sat, 7 Jan 2023, Markus Elfring wrote:

> >>> or make a pattern that contains one element followed by a list.
> >> Would this design variant need pairs of metavariables?
> >>
> >>
> >> How do you think about the possibility to add a corresponding metavariable
> >> type like “array”?
> > Array does not suggest to me anything like what you are asking for.
>
> Which data type name would you find more appropriate for the ordered storage
> of a varying number of items?

We already have list for that.  With constraints, as illustrated in the
previous message, that is sufficient.

julia

Re: [cocci] Working with filled data structures

[Markus Elfring]

>> Which data type name would you find more appropriate for the ordered storage
>> of a varying number of items?
> We already have list for that.  With constraints, as illustrated in the
> previous message, that is sufficient.

This design approach has got the side effect that pairs of metavariables
are required for the discussed use case.

Regards,
Markus