* [Cocci] Challenges around asterisk usage in SmPL code
@ 2019-08-24 17:33 Markus Elfring
[not found] ` <2AE15A09-F219-43DC-81A9-73C13CFC0753@lip6.fr>
0 siblings, 1 reply; 15+ messages in thread
From: Markus Elfring @ 2019-08-24 17:33 UTC (permalink / raw)
To: Coccinelle
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
^ permalink raw reply [flat|nested] 15+ messages in thread[parent not found: <2AE15A09-F219-43DC-81A9-73C13CFC0753@lip6.fr>]
* Re: [Cocci] Challenges around asterisk usage in SmPL code [not found] ` <2AE15A09-F219-43DC-81A9-73C13CFC0753@lip6.fr> @ 2019-08-25 7:40 ` Markus Elfring 2019-08-25 7:48 ` Julia Lawall 0 siblings, 1 reply; 15+ messages in thread From: Markus Elfring @ 2019-08-25 7:40 UTC (permalink / raw) To: Julia Lawall; +Cc: Coccinelle >> @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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Cocci] Challenges around asterisk usage in SmPL code 2019-08-25 7:40 ` Markus Elfring @ 2019-08-25 7:48 ` Julia Lawall 2019-08-25 8:13 ` Markus Elfring ` (2 more replies) 0 siblings, 3 replies; 15+ messages in thread From: Julia Lawall @ 2019-08-25 7:48 UTC (permalink / raw) To: Markus Elfring; +Cc: Coccinelle [-- 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Cocci] Challenges around asterisk usage in SmPL code 2019-08-25 7:48 ` Julia Lawall @ 2019-08-25 8:13 ` Markus Elfring 2019-08-25 8:30 ` [Cocci] Searching for unary operations with SmPL Markus Elfring 2019-08-25 9:11 ` [Cocci] Challenges around asterisk usage in SmPL code Markus Elfring 2 siblings, 0 replies; 15+ messages in thread From: Markus Elfring @ 2019-08-25 8:13 UTC (permalink / raw) To: Julia Lawall; +Cc: Coccinelle >>> 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Cocci] Searching for unary operations with SmPL 2019-08-25 7:48 ` Julia Lawall 2019-08-25 8:13 ` Markus Elfring @ 2019-08-25 8:30 ` Markus Elfring 2019-08-25 9:11 ` [Cocci] Challenges around asterisk usage in SmPL code Markus Elfring 2 siblings, 0 replies; 15+ messages in thread From: Markus Elfring @ 2019-08-25 8:30 UTC (permalink / raw) To: Julia Lawall; +Cc: Coccinelle >> 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Cocci] Challenges around asterisk usage in SmPL code 2019-08-25 7:48 ` Julia Lawall 2019-08-25 8:13 ` Markus Elfring 2019-08-25 8:30 ` [Cocci] Searching for unary operations with SmPL Markus Elfring @ 2019-08-25 9:11 ` Markus Elfring 2019-08-25 9:45 ` Julia Lawall 2 siblings, 1 reply; 15+ messages in thread From: Markus Elfring @ 2019-08-25 9:11 UTC (permalink / raw) To: Julia Lawall; +Cc: Coccinelle >> 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Cocci] Challenges around asterisk usage in SmPL code 2019-08-25 9:11 ` [Cocci] Challenges around asterisk usage in SmPL code Markus Elfring @ 2019-08-25 9:45 ` Julia Lawall 2019-08-25 10:22 ` Markus Elfring ` (2 more replies) 0 siblings, 3 replies; 15+ messages in thread From: Julia Lawall @ 2019-08-25 9:45 UTC (permalink / raw) To: Markus Elfring; +Cc: Coccinelle 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Cocci] Challenges around asterisk usage in SmPL code 2019-08-25 9:45 ` Julia Lawall @ 2019-08-25 10:22 ` Markus Elfring 2019-08-25 13:13 ` [Cocci] Checking information from “--parse-cocci” Markus Elfring 2019-08-25 17:34 ` [Cocci] Challenges around asterisk usage in SmPL code Markus Elfring 2019-08-26 17:26 ` [Cocci] Checking null pointer handling with SmPL Markus Elfring 2 siblings, 1 reply; 15+ messages in thread From: Markus Elfring @ 2019-08-25 10:22 UTC (permalink / raw) To: Julia Lawall; +Cc: Coccinelle >> @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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Cocci] Checking information from “--parse-cocci” 2019-08-25 10:22 ` Markus Elfring @ 2019-08-25 13:13 ` Markus Elfring [not found] ` <alpine.DEB.2.21.1908252118210.2801@hadrien> 0 siblings, 1 reply; 15+ messages in thread From: Markus Elfring @ 2019-08-25 13:13 UTC (permalink / raw) To: Julia Lawall; +Cc: Coccinelle >> 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <alpine.DEB.2.21.1908252118210.2801@hadrien>]
* Re: [Cocci] Checking information from “--parse-cocci” [not found] ` <alpine.DEB.2.21.1908252118210.2801@hadrien> @ 2019-08-25 13:45 ` Markus Elfring [not found] ` <alpine.DEB.2.21.1908252209170.3506@hadrien> 0 siblings, 1 reply; 15+ messages in thread From: Markus Elfring @ 2019-08-25 13:45 UTC (permalink / raw) To: Julia Lawall; +Cc: Coccinelle >> 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <alpine.DEB.2.21.1908252209170.3506@hadrien>]
* Re: [Cocci] Checking information from “--parse-cocci” [not found] ` <alpine.DEB.2.21.1908252209170.3506@hadrien> @ 2019-08-25 14:19 ` Markus Elfring 0 siblings, 0 replies; 15+ messages in thread From: Markus Elfring @ 2019-08-25 14:19 UTC (permalink / raw) To: Julia Lawall; +Cc: Coccinelle > 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Cocci] Challenges around asterisk usage in SmPL code 2019-08-25 9:45 ` Julia Lawall 2019-08-25 10:22 ` Markus Elfring @ 2019-08-25 17:34 ` Markus Elfring 2019-08-26 17:26 ` [Cocci] Checking null pointer handling with SmPL Markus Elfring 2 siblings, 0 replies; 15+ messages in thread From: Markus Elfring @ 2019-08-25 17:34 UTC (permalink / raw) To: Julia Lawall; +Cc: Coccinelle > 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Cocci] Checking null pointer handling with SmPL 2019-08-25 9:45 ` Julia Lawall 2019-08-25 10:22 ` Markus Elfring 2019-08-25 17:34 ` [Cocci] Challenges around asterisk usage in SmPL code Markus Elfring @ 2019-08-26 17:26 ` Markus Elfring 2019-08-27 0:58 ` Julia Lawall 2 siblings, 1 reply; 15+ messages in thread From: Markus Elfring @ 2019-08-26 17:26 UTC (permalink / raw) To: Julia Lawall; +Cc: Jia-Ju Bai, Coccinelle > 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Cocci] Checking null pointer handling with SmPL 2019-08-26 17:26 ` [Cocci] Checking null pointer handling with SmPL Markus Elfring @ 2019-08-27 0:58 ` Julia Lawall 2019-08-28 11:50 ` Markus Elfring 0 siblings, 1 reply; 15+ messages in thread From: Julia Lawall @ 2019-08-27 0:58 UTC (permalink / raw) To: Markus Elfring; +Cc: Jia-Ju Bai, Coccinelle [-- 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Cocci] Checking null pointer handling with SmPL 2019-08-27 0:58 ` Julia Lawall @ 2019-08-28 11:50 ` Markus Elfring 0 siblings, 0 replies; 15+ messages in thread From: Markus Elfring @ 2019-08-28 11:50 UTC (permalink / raw) To: Julia Lawall; +Cc: Jia-Ju Bai, Coccinelle > 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2019-08-28 11:50 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-24 17:33 [Cocci] Challenges around asterisk usage in SmPL code Markus Elfring
[not found] ` <2AE15A09-F219-43DC-81A9-73C13CFC0753@lip6.fr>
2019-08-25 7:40 ` Markus Elfring
2019-08-25 7:48 ` Julia Lawall
2019-08-25 8:13 ` Markus Elfring
2019-08-25 8:30 ` [Cocci] Searching for unary operations with SmPL Markus Elfring
2019-08-25 9:11 ` [Cocci] Challenges around asterisk usage in SmPL code Markus Elfring
2019-08-25 9:45 ` Julia Lawall
2019-08-25 10:22 ` Markus Elfring
2019-08-25 13:13 ` [Cocci] Checking information from “--parse-cocci” Markus Elfring
[not found] ` <alpine.DEB.2.21.1908252118210.2801@hadrien>
2019-08-25 13:45 ` Markus Elfring
[not found] ` <alpine.DEB.2.21.1908252209170.3506@hadrien>
2019-08-25 14:19 ` Markus Elfring
2019-08-25 17:34 ` [Cocci] Challenges around asterisk usage in SmPL code Markus Elfring
2019-08-26 17:26 ` [Cocci] Checking null pointer handling with SmPL Markus Elfring
2019-08-27 0:58 ` Julia Lawall
2019-08-28 11:50 ` Markus Elfring
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).