* [Cocci] Checking data structure modification with SmPL
@ 2015-08-18 11:34 SF Markus Elfring
2015-08-22 14:17 ` Julia Lawall
0 siblings, 1 reply; 8+ messages in thread
From: SF Markus Elfring @ 2015-08-18 11:34 UTC (permalink / raw)
To: cocci
Hello,
I have tried another small SmPL script out.
@show_modification_before_memory_release@
expression value;
identifier element, var;
@@
<+...
*var->element = value;
...+>
free(var);
This approach is working to some degree.
Now I would like to support more possibilities for the determination
of affected members from the shown variable.
@show_modification_before_memory_release@
expression element, value;
identifier var;
@@
<+...
*var->element = value;
...+>
free(var);
elfring at Sonne:~/Projekte/Miller/lokal> spatch.opt -sp-file ~/Projekte/Coccinelle/janitor/show_modification_before_memory_release1.cocci c/containers/hss.c
init_defs_builtins: /usr/local/lib/coccinelle/standard.h
101 108
Fatal error: exception Failure("minus: parse error: \n = File \"/home/elfring/Projekte/Coccinelle/janitor/show_modification_before_memory_release1.cocci\", line 6, column 6, charpos = 101\n around = 'element', whole content = *var->element = value;\n")
How can this source code analysis be improved?
Regards,
Markus
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Cocci] Checking data structure modification with SmPL
2015-08-18 11:34 [Cocci] Checking data structure modification with SmPL SF Markus Elfring
@ 2015-08-22 14:17 ` Julia Lawall
2015-08-22 15:58 ` SF Markus Elfring
0 siblings, 1 reply; 8+ messages in thread
From: Julia Lawall @ 2015-08-22 14:17 UTC (permalink / raw)
To: cocci
On Tue, 18 Aug 2015, SF Markus Elfring wrote:
> Hello,
>
> I have tried another small SmPL script out.
>
> @show_modification_before_memory_release@
> expression value;
> identifier element, var;
> @@
> <+...
> *var->element = value;
> ...+>
> free(var);
>
>
> This approach is working to some degree.
> Now I would like to support more possibilities for the determination
> of affected members from the shown variable.
>
>
> @show_modification_before_memory_release@
> expression element, value;
> identifier var;
> @@
> <+...
> *var->element = value;
Element is not an expression. An expression is something that has a
value. A field name has no value. It just enables selecting a field.
Probably what you want is <+...var->element...+>, ie something that has
var->element as a subexpression. To avoid parsing ambiguities, you will
need to put () around this, but it will not affect the results.
julia
> ...+>
> free(var);
>
>
> elfring at Sonne:~/Projekte/Miller/lokal> spatch.opt -sp-file ~/Projekte/Coccinelle/janitor/show_modification_before_memory_release1.cocci c/containers/hss.c
> init_defs_builtins: /usr/local/lib/coccinelle/standard.h
> 101 108
> Fatal error: exception Failure("minus: parse error: \n = File \"/home/elfring/Projekte/Coccinelle/janitor/show_modification_before_memory_release1.cocci\", line 6, column 6, charpos = 101\n around = 'element', whole content = *var->element = value;\n")
>
>
> How can this source code analysis be improved?
>
> Regards,
> Markus
> _______________________________________________
> Cocci mailing list
> Cocci at systeme.lip6.fr
> https://systeme.lip6.fr/mailman/listinfo/cocci
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Cocci] Checking data structure modification with SmPL
2015-08-22 14:17 ` Julia Lawall
@ 2015-08-22 15:58 ` SF Markus Elfring
2015-08-22 16:05 ` Julia Lawall
0 siblings, 1 reply; 8+ messages in thread
From: SF Markus Elfring @ 2015-08-22 15:58 UTC (permalink / raw)
To: cocci
>> Now I would like to support more possibilities for the determination
>> of affected members from the shown variable.
>>
>>
>> @show_modification_before_memory_release@
>> expression element, value;
>> identifier var;
>> @@
>> <+...
>> *var->element = value;
>
> Element is not an expression. An expression is something that has a value.
> A field name has no value. It just enables selecting a field.
Thanks for your clarification.
> Probably what you want is <+...var->element...+>, ie something that has
> var->element as a subexpression.
* Do I need to restrict the amount of source code which can appear between
data structure access and the shown value assignment that should be checked
by such a SmPL construct?
* Do I need to fiddle with another SmPL disjunction to express
the possibility that "var" could be more than a simple identifier?
* How should the support for longer arrow chains be specified?
> To avoid parsing ambiguities, you will need to put () around this,
> but it will not affect the results.
Thanks for this hint.
>> ...+>
>> free(var);
Regards,
Markus
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Cocci] Checking data structure modification with SmPL
2015-08-22 15:58 ` SF Markus Elfring
@ 2015-08-22 16:05 ` Julia Lawall
2015-08-22 16:50 ` SF Markus Elfring
0 siblings, 1 reply; 8+ messages in thread
From: Julia Lawall @ 2015-08-22 16:05 UTC (permalink / raw)
To: cocci
On Sat, 22 Aug 2015, SF Markus Elfring wrote:
> >> Now I would like to support more possibilities for the determination
> >> of affected members from the shown variable.
> >>
> >>
> >> @show_modification_before_memory_release@
> >> expression element, value;
> >> identifier var;
> >> @@
> >> <+...
> >> *var->element = value;
> >
> > Element is not an expression. An expression is something that has a value.
> > A field name has no value. It just enables selecting a field.
>
> Thanks for your clarification.
>
>
> > Probably what you want is <+...var->element...+>, ie something that has
> > var->element as a subexpression.
>
> * Do I need to restrict the amount of source code which can appear between
> data structure access and the shown value assignment that should be checked
> by such a SmPL construct?
Since I don'tknow what you want to do, I can't tell you. If there are
somefixed patterns you want to find, it would be better to enumerate those
fixed patterns.
> * Do I need to fiddle with another SmPL disjunction to express
> the possibility that "var" could be more than a simple identifier?
Ultimately, var shouldend up at an identifier, so I don't see the need.
> * How should the support for longer arrow chains be specified?
No idea what you are asking, but I am not keen on adding yet another
metavariable type for this, which anyway doesn't correspond to anything in
the C grammar.
julia
>
>
> > To avoid parsing ambiguities, you will need to put () around this,
> > but it will not affect the results.
>
> Thanks for this hint.
>
>
> >> ...+>
> >> free(var);
>
>
> Regards,
> Markus
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Cocci] Checking data structure modification with SmPL
2015-08-22 16:05 ` Julia Lawall
@ 2015-08-22 16:50 ` SF Markus Elfring
2015-08-22 19:07 ` Julia Lawall
0 siblings, 1 reply; 8+ messages in thread
From: SF Markus Elfring @ 2015-08-22 16:50 UTC (permalink / raw)
To: cocci
>> * Do I need to fiddle with another SmPL disjunction to express
>> the possibility that "var" could be more than a simple identifier?
>
> Ultimately, var shouldend up at an identifier, so I don't see the need.
How do you think about a variant like the following?
(expression)->element
>> * How should the support for longer arrow chains be specified?
>
> No idea what you are asking, but I am not keen on adding yet another
> metavariable type for this, which anyway doesn't correspond to anything in
> the C grammar.
Does the following approach make my consideration a bit more clear?
var->(expression)->(expression)->element
How should a more detailed pointer access variation be handled here?
Regards,
Markus
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Cocci] Checking data structure modification with SmPL
2015-08-22 16:50 ` SF Markus Elfring
@ 2015-08-22 19:07 ` Julia Lawall
2015-08-22 20:01 ` SF Markus Elfring
0 siblings, 1 reply; 8+ messages in thread
From: Julia Lawall @ 2015-08-22 19:07 UTC (permalink / raw)
To: cocci
On Sat, 22 Aug 2015, SF Markus Elfring wrote:
> >> * Do I need to fiddle with another SmPL disjunction to express
> >> the possibility that "var" could be more than a simple identifier?
> >
> > Ultimately, var shouldend up at an identifier, so I don't see the need.
>
> How do you think about a variant like the following?
>
> (expression)->element
This is certainly possible. Depends whether you want the innermost
variable or the outermost expression.
>
>
> >> * How should the support for longer arrow chains be specified?
> >
> > No idea what you are asking, but I am not keen on adding yet another
> > metavariable type for this, which anyway doesn't correspond to anything in
> > the C grammar.
>
> Does the following approach make my consideration a bit more clear?
>
> var->(expression)->(expression)->element
This makes no sense. If you have a->b->c->d->e, then eg b->c->d is not an
expression. It has no value.
julia
>
> How should a more detailed pointer access variation be handled here?
>
> Regards,
> Markus
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Cocci] Checking data structure modification with SmPL
2015-08-22 19:07 ` Julia Lawall
@ 2015-08-22 20:01 ` SF Markus Elfring
[not found] ` <alpine.DEB.2.10.1508221303590.2446@hadrien>
0 siblings, 1 reply; 8+ messages in thread
From: SF Markus Elfring @ 2015-08-22 20:01 UTC (permalink / raw)
To: cocci
> If you have a->b->c->d->e, then eg b->c->d is not an expression.
I have got an other opinion here.
* Can each part between the pointer access operators be an expression?
* How long can such a structure member access chain become
in interesting source codes?
Regards,
Markus
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Cocci] Checking data structure modification with SmPL
[not found] ` <alpine.DEB.2.10.1508221303590.2446@hadrien>
@ 2015-08-22 20:50 ` SF Markus Elfring
0 siblings, 0 replies; 8+ messages in thread
From: SF Markus Elfring @ 2015-08-22 20:50 UTC (permalink / raw)
To: cocci
>> * Can each part between the pointer access operators be an expression?
>
> No. In a->b->c->d->e, b->c->d has no value. It even has no meaning
> independent of the type of a.
Which wording would be more appropriate from the point of view
in the syntax of the C programming language?
>> * How long can such a structure member access chain become
>> in interesting source codes?
>
> I guess as long as the greatest nesting depth of structures in the program.
> If the program contains structures of recursive type, it ca have
> any length.
Can I prepare SmPL scripts to handle variations there?
How are the chances to avoid the consideration and source code analysis around
only a limited number of structure member accesses?
Regards,
Markus
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2015-08-22 20:50 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-08-18 11:34 [Cocci] Checking data structure modification with SmPL SF Markus Elfring
2015-08-22 14:17 ` Julia Lawall
2015-08-22 15:58 ` SF Markus Elfring
2015-08-22 16:05 ` Julia Lawall
2015-08-22 16:50 ` SF Markus Elfring
2015-08-22 19:07 ` Julia Lawall
2015-08-22 20:01 ` SF Markus Elfring
[not found] ` <alpine.DEB.2.10.1508221303590.2446@hadrien>
2015-08-22 20:50 ` SF Markus Elfring
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.