[Cocci] Checking data structure modification with SmPL

[Cocci] Checking data structure modification with SmPL

[SF Markus Elfring]

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

[Cocci] Checking data structure modification with SmPL

[Julia Lawall]

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
>

[Cocci] Checking data structure modification with SmPL

[SF Markus Elfring]

>> 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

[Cocci] Checking data structure modification with SmPL

[Julia Lawall]

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
>

[Cocci] Checking data structure modification with SmPL

[SF Markus Elfring]

>> * 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

[Cocci] Checking data structure modification with SmPL

[Julia Lawall]

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
>

[Cocci] Checking data structure modification with SmPL

[SF Markus Elfring]

> 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

[Cocci] Checking data structure modification with SmPL

[SF Markus Elfring]

>> * 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