[Cocci] Challenges around asterisk usage in SmPL code

[Cocci] Challenges around asterisk usage in SmPL code

[Markus Elfring]

Hello,

The programming languages “C” and “C++” support functionality where characters
can be ambiguous:
The asterisk can be used for the specification of multiplications
or pointer dereferences (for example).
https://softwareengineering.stackexchange.com/questions/124570/why-pointer-symbol-and-multiplication-sign-are-same-in-c-c

Now I would like to specify a source code search for the case that
unary operations would be used within computations.
The Coccinelle software accepts the following approach.

@assignment@
expression x, y;
@@
* y = ... *(x) ...;


I became curious if another small script for the semantic patch languages
should also work then.

@check@
expression x, y;
statement es;
@@
*if ( \( !(x) \| x == NULL \) )
*   y = ... *(x) ...;
 else
    es


But a parse error is reported so far for this code variant.
How will the software situation evolve further around such challenges?

Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Challenges around asterisk usage in SmPL code

[Markus Elfring]

>> @assignment@
>> expression x, y;
>> @@
>> * y = ... *(x) ...;
>
> This doesn’t do what you think.

This might be.


> It matches a series of statements, I’m not even completely sure how.

Such a feedback is also interesting.
My imaginations evolved in other directions.


> There can’t be a series of statements before an else.

This view can depend on the interpretation around the handling of compound statements,
can't it?


> You want <+...  ...+>

Does this SmPL construct help to restrict a source code search element
(while using SmPL ellipses) to a single statement for the shown analysis example?

Will the support for unary operations need any further development considerations?

Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Challenges around asterisk usage in SmPL code

[Julia Lawall]

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



On Sun, 25 Aug 2019, Markus Elfring wrote:

> >> @assignment@
> >> expression x, y;
> >> @@
> >> * y = ... *(x) ...;
> >
> > This doesn’t do what you think.
>
> This might be.
>
>
> > It matches a series of statements, I’m not even completely sure how.
>
> Such a feedback is also interesting.
> My imaginations evolved in other directions.
>
>
> > There can’t be a series of statements before an else.
>
> This view can depend on the interpretation around the handling of compound statements,
> can't it?
>
>
> > You want <+...  ...+>
>
> Does this SmPL construct help to restrict a source code search element
> (while using SmPL ellipses) to a single statement for the shown analysis example?

Yes.

>
> Will the support for unary operations need any further development considerations?

No, the precedence should be ok as is.

julia

> Regards,
> Markus
>

[-- Attachment #2: Type: text/plain, Size: 136 bytes --]

_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Challenges around asterisk usage in SmPL code

[Markus Elfring]

>>> You want <+...  ...+>
>>
>> Does this SmPL construct help to restrict a source code search element
>> (while using SmPL ellipses) to a single statement for the shown analysis example?
>
> Yes.

Thanks for the clarification.

Will this information become more helpful also for a better software documentation?

Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Searching for unary operations with SmPL

[Markus Elfring]

>> Will the support for unary operations need any further development considerations?
>
> No, the precedence should be ok as is.

I got another idea.

The semantic patch language supports the metavariable type “binary operator”.
https://github.com/coccinelle/coccinelle/blob/b4509f6e7fb06d5616bb19dd5a110b203fd0e566/docs/manual/cocci_syntax.tex#L266

How do you think about to add the construct “unary operator”?

Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Challenges around asterisk usage in SmPL code

[Markus Elfring]

>> Does this SmPL construct help to restrict a source code search element
>> (while using SmPL ellipses) to a single statement for the shown analysis example?
>
> Yes.

I get a parse error also for the following SmPL script variant.

@check@
expression x;
statement es;
@@
*if ( \( !(x) \| x == NULL \) )
*   <+... *(x) ...+>;
 else
    es


Can it be avoided to express assignment variations explicitly?

Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Challenges around asterisk usage in SmPL code

[Julia Lawall]

On Sun, 25 Aug 2019, Markus Elfring wrote:

> >> Does this SmPL construct help to restrict a source code search element
> >> (while using SmPL ellipses) to a single statement for the shown analysis example?
> >
> > Yes.
>
> I get a parse error also for the following SmPL script variant.
>
> @check@
> expression x;
> statement es;
> @@
> *if ( \( !(x) \| x == NULL \) )
> *   <+... *(x) ...+>;
>  else
>     es
>
>
> Can it be avoided to express assignment variations explicitly?

I don't know what you are trying to do.  Previously, you had the beginning
of an assignment before the ...  I suggested to replace the ... before and
after the *(x) by <+... ...+>.  Strangely you have deleted the assignment
part as well.

Your code line with the <+... ...+> ends with a ;.  So the <+... ...+>
must match an expression (which could be an assignment).  But due to
parsing priorities, <+... ...+> that is unknown is parsed as a statement.
So the ; causes a parse error.  To force the <+... ...+> to be parsed as
an expression, you have to surround it with ().  An isomorphism will
normally cause the case without the parentheses to be considered as well.

None of this has anything to do with unary operators.

julia
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Challenges around asterisk usage in SmPL code

[Markus Elfring]

>> @check@
>> expression x;
>> statement es;
>> @@
>> *if ( \( !(x) \| x == NULL \) )
>> *   <+... *(x) ...+>;
>>  else
>>     es
>>
>>
>> Can it be avoided to express assignment variations explicitly?
>
> I don't know what you are trying to do.

Can you get the impression that I am trying also to achieve something
around the detection of null pointer usage?


> Previously, you had the beginning of an assignment before the ...
> I suggested to replace the ... before and after the *(x) by <+... ...+>.

This variant gets accepted by the Coccinelle software.


> Strangely you have deleted the assignment part as well.

I became curious if such an approach should also work.


> Your code line with the <+... ...+> ends with a ;.

Yes - for this test.


> So the <+... ...+> must match an expression (which could be an assignment).

This can be appropriate.


> But due to parsing priorities, <+... ...+> that is unknown is parsed as a statement.
> So the ; causes a parse error.  To force the <+... ...+> to be parsed as
> an expression, you have to surround it with ().  An isomorphism will
> normally cause the case without the parentheses to be considered as well.

Thanks for this explanation.


> None of this has anything to do with unary operators.

This view is reasonable.

I just put a search pattern with an asterisk into this SmPL construct.

Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Checking information from “--parse-cocci”

[Markus Elfring]

>> To force the <+... ...+> to be parsed as an expression, you have to surround it with ().

I was unused to this technical detail.
Will such information become more helpful also for a better software documentation?

I adjusted my evolving search pattern a bit more.
I looked at the output from the command “spatch --parse-cocci …” again.
I find a display like the following questionable then.

“…
)) eselse {
  ...   WHEN any   WHEN != x = y;
…”


Would another delimiter be better in the output like “)) es else {” here?

Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Checking information from “--parse-cocci”

[Markus Elfring]

>> Would another delimiter be better in the output like “)) es else {” here?
>
> I don't know what the semantic patch is, so I can't answer the question.

Can you find the OCaml print statement (better than me)
where an identifier metavariable is displayed together with the mentioned
key word without a helpful delimiter between these items?

Another SmPL script example:
@display@
expression x, y;
identifier action;
statement es;
@@
*if ( \( !(x) \| (x) == NULL \) )
 {
 ... when any
     when != x = y;
    (<+...
(
*   *(x)
|
*   action(..., x, ...)
)
    ...+>);
 ... when any
 }
 else
    es


Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Checking information from “--parse-cocci”

[Markus Elfring]

> This is just printing for debugging purposes.

Should the provided data become better understandable by more software users?

Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Challenges around asterisk usage in SmPL code

[Markus Elfring]

> I don't know what you are trying to do.

I have constructed another SmPL script variant.

@display@
expression x;
identifier action;
statement es;
@@
*if (!x)
    (<+...
(   sizeof(*x)
|
*   *x
|   action(...,
*          x
           , ...)
)
    ...+>);
 else
    es


This approach looks promising at the first glance.
Unfortunately, a corresponding test example shows that it is
still incomplete.

elfring@Sonne:~/Projekte/Linux/next-patched> spatch ~/Projekte/Coccinelle/janitor/show_null_pointer_usage7.cocci init/main.c
…
@@ -815,9 +815,7 @@ static int __init initcall_blacklist(cha
…
 			entry = memblock_alloc(sizeof(*entry),
 					       SMP_CACHE_BYTES);
-			if (!entry)
 				panic("%s: Failed to allocate %zu bytes\n",
-				      __func__, sizeof(*entry));
…


Would you like to suggest any extensions for the exclusion
of such false positives?

Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Checking null pointer handling with SmPL

[Markus Elfring]

> I don't know what you are trying to do.

I am trying another software analysis approach out for the presentation
of null pointer usage.

Jia-Ju Bai contributed patches based on analysis results from
the tool “STCheck” by the OSLAB group of the Tsinghua University.
Some corresponding improvements are in the review queue.

A specific script is available also for the semantic patch language.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/coccinelle/null/deref_null.cocci?id=a55aa89aab90fae7c815b0551b07be37db359d76

Can this SmPL script become able to point remaining update candidates out
in similar ways?

Examples for further considerations:
* fs: xfs: Fix possible null-pointer dereferences in xchk_da_btree_block_check_sibling()
  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/xfs/scrub/dabtree.c?id=afa1d96d1430c2138c545fb76e6dcb21222098d4
  https://lore.kernel.org/lkml/20190729032401.28081-1-baijiaju1990@gmail.com/
  https://lore.kernel.org/patchwork/patch/1106628/
  https://lkml.org/lkml/2019/7/28/344

* scsi: libiscsi: Fix possible null-pointer dereferences in iscsi_conn_get_addr_param()
  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/libiscsi.c?id=a55aa89aab90fae7c815b0551b07be37db359d76#n3455
  https://lore.kernel.org/lkml/20190729091339.30815-1-baijiaju1990@gmail.com/
  https://lore.kernel.org/patchwork/patch/1106725/
  https://lkml.org/lkml/2019/7/29/228

Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Checking null pointer handling with SmPL

[Julia Lawall]

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



On Mon, 26 Aug 2019, Markus Elfring wrote:

> > I don't know what you are trying to do.
>
> I am trying another software analysis approach out for the presentation
> of null pointer usage.
>
> Jia-Ju Bai contributed patches based on analysis results from
> the tool “STCheck” by the OSLAB group of the Tsinghua University.
> Some corresponding improvements are in the review queue.
>
> A specific script is available also for the semantic patch language.
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/coccinelle/null/deref_null.cocci?id=a55aa89aab90fae7c815b0551b07be37db359d76
>
> Can this SmPL script become able to point remaining update candidates out
> in similar ways?

STCheck does interprocedural analysis, and has some features for path
sensitivity.  I haven't looked at these specific reports in detail, but in
general, the kinds of bugs found by STCheck may be difficult or
inconvenient to find with Coccinelle.  On the other hand, STCheck doesn't
have a particularly friendly language for specifying rules, at least not
for the moment.

julia


>
> Examples for further considerations:
> * fs: xfs: Fix possible null-pointer dereferences in xchk_da_btree_block_check_sibling()
>   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/xfs/scrub/dabtree.c?id=afa1d96d1430c2138c545fb76e6dcb21222098d4
>   https://lore.kernel.org/lkml/20190729032401.28081-1-baijiaju1990@gmail.com/
>   https://lore.kernel.org/patchwork/patch/1106628/
>   https://lkml.org/lkml/2019/7/28/344
>
> * scsi: libiscsi: Fix possible null-pointer dereferences in iscsi_conn_get_addr_param()
>   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/libiscsi.c?id=a55aa89aab90fae7c815b0551b07be37db359d76#n3455
>   https://lore.kernel.org/lkml/20190729091339.30815-1-baijiaju1990@gmail.com/
>   https://lore.kernel.org/patchwork/patch/1106725/
>   https://lkml.org/lkml/2019/7/29/228
>
> Regards,
> Markus
>

[-- Attachment #2: Type: text/plain, Size: 136 bytes --]

_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Checking null pointer handling with SmPL

[Markus Elfring]

> STCheck does interprocedural analysis, and has some features for path sensitivity.

How do you think about to add any related information for such technology?


>  I haven't looked at these specific reports in detail
> …, but in general, the kinds of bugs found by STCheck may be difficult

Would you like to adjust remaining difficulties?


> or inconvenient to find with Coccinelle.

Can inconveniences be reduced any further for discussed software analysis approaches?

Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci