[Cocci] Finding function implementations that call only a single function.

[Cocci] Finding function implementations that call only a single function.

[SF Markus Elfring]

Hello,

I would like to try another specific source code analysis out.
My approach contains the following semantic patch rule.

@non_void_single_function_call@
identifier caller, input, result, work;
type data_type,
     input_type,
     return_type !~ "void";
position pos;
@@
 return_type caller at pos(input_type input)
 {
(
  return work(input);
|
  data_type result = work(input);
  return result;
)
 }


But I wonder about the following error message.

elfring at Sonne:~/Projekte/Coccinelle/Probe> spatch.opt -sp-file list_functions_with_single_function_call1.cocci -dir /usr/src/linux-stable/drivers/gpu/drm/ast
init_defs_builtins: /usr/local/share/coccinelle/standard.h
1612 1614
Fatal error: exception Failure("meta: parse error: 
 = File "list_functions_with_single_function_call1.cocci", line 77, column 17,  charpos = 1612
    around = '!~', whole content =      return_type !~ "void";
")


Regards,
Markus

[Cocci] Finding function implementations that call only a single function.

[SF Markus Elfring]

>> How should function calls with a non-void return type be found currently?
> 
> Perhaps you can say
> 
> type t != void;

I have tried your suggestion out.


elfring at Sonne:~/Projekte/Coccinelle/Probe> spatch.opt -sp-file list_functions_with_single_function_call3.cocci /usr/src/linux-stable/drivers/gpu/drm/ast/ast_ttm.c
init_defs_builtins: /usr/local/share/coccinelle/standard.h
1847 1849
Fatal error: exception Failure("meta: parse error: 
 = File "list_functions_with_single_function_call3.cocci", line 82, column 17,  charpos = 1847
    around = '!=', whole content =      return_type != void;
")


But I do not like the shown error message again.


> If not, then match the void functions, save their position, and then match 
> the functions that are not in the same position.

I would appreciate if I do not need to fiddle more with SmPL position variables.

Regards,
Markus

[Cocci] Finding function implementations that call only a single function.

[SF Markus Elfring]

> OK, you hve two choices:
> 
> 1. Use the position variables

I might consider their use more for other data processing tasks.


> 2. Extend Coccinelle to handle constraints on types

Would you like to acknowledge that this implementation area
is still an open issue?
https://github.com/coccinelle/coccinelle/issues/32

How do you think about do document corresponding limitations?


> Or I guess a third choice which is to use some other tool.

I can also fiddle with SmPL rules which try to circumvent current
software limitations as a fourth choice, can't we?

I guess that it should work at least to filter on function
implementations which call only a single function.
The missing support for constraints on metavariables with
the data type "type" might not really matter in this specific
use case.

Example:

@non_void_single_function_call@
identifier caller, input, result, work;
type data_type, input_type, return_type;
@@
*return_type caller(..., input_type input, ...)
 {
(
  return work(input);
|
  data_type result = work(input);
  return result;
)
 }

elfring at Sonne:~/Projekte/Coccinelle/Probe> spatch.opt -sp-file find_non-void_function2.cocci /usr/src/linux-stable/drivers/gpu/drm/ast/ast_ttm.c
init_defs_builtins: /usr/local/share/coccinelle/standard.h
HANDLING: /usr/src/linux-stable/drivers/gpu/drm/ast/ast_ttm.c
diff =
--- /usr/src/linux-stable/drivers/gpu/drm/ast/ast_ttm.c
+++ /tmp/cocci-output-20396-ddaa9b-ast_ttm.c
@@ -225,7 +225,6 @@ static struct ttm_tt *ast_ttm_tt_create(
        return tt;
 }

-static int ast_ttm_tt_populate(struct ttm_tt *ttm)
 {
        return ttm_pool_populate(ttm);
 }


A wrapper function was found here which has got also the property "static".
I am trying to improve my source code analysis scripts especially for
this function type.


How do you think about the following differences in the results?

elfring at Sonne:~/Projekte/Coccinelle/Probe> spatch.opt -sp-file list_functions_with_single_function_call3.cocci /usr/src/linux-stable/drivers/gpu/drm/ast/ast_ttm.c
init_defs_builtins: /usr/local/share/coccinelle/standard.h
warning: void_find_static: inherited metavariable caller not used in the -, +, or context code
warning: non_void_find_static: inherited metavariable caller not used in the -, +, or context code
HANDLING: /usr/src/linux-stable/drivers/gpu/drm/ast/ast_ttm.c
static|function|"data type"|"parameter"|"source file"|line|column
0|ast_ttm_tt_unpopulate|"struct ttm_tt *"|ttm|"/usr/src/linux-stable/drivers/gpu/drm/ast/ast_ttm.c"|233|13
elfring at Sonne:~/Projekte/Coccinelle/Probe> spatch.opt -sp-file list_functions_with_single_function_call4.cocci /usr/src/linux-stable/drivers/gpu/drm/ast/ast_ttm.c
init_defs_builtins: /usr/local/share/coccinelle/standard.h
warning: find_static: inherited metavariable caller not used in the -, +, or context code
HANDLING: /usr/src/linux-stable/drivers/gpu/drm/ast/ast_ttm.c
static|function|"data type"|"parameter"|"source file"|line|column
0|ast_ttm_tt_populate|"struct ttm_tt *"|ttm|"/usr/src/linux-stable/drivers/gpu/drm/ast/ast_ttm.c"|228|12
0|ast_ttm_tt_unpopulate|"struct ttm_tt *"|ttm|"/usr/src/linux-stable/drivers/gpu/drm/ast/ast_ttm.c"|233|13


* Both approaches should find more functions here, shouldn't they?
  (See attachments ...)

* It seems that my python function "store_static" is not called so far.
  Is that strange?

Regards,
Markus
-------------- next part --------------
@initialize:python@
@@
import sys
import sqlite3 as SQLite
connection = SQLite.connect(":memory:")
c = connection.cursor()
c.execute("""
create table positions
(static integer default 0,
 function text,
 data_type text,
 parameter text,
 source_file text,
 line integer,
 column integer,
 constraint c
 primary key (function, source_file, line, column)
)
without rowid""")
build_index=True

def store_positions(fun, typ, point, places):
    """Add source code positions to an internal list."""
    for place in places:
        c.execute("""insert into positions
(function,
 data_type,
 parameter,
 source_file,
 line,
 column
)
values (?, ?, ?, ?, ?, ?)""",
                  (fun,
                  typ,
                  point,
                  place.file,
                  place.line,
                  int(place.column) + 1
                  )
                 )

def store_static(fun, places):
    """Record that a function is static."""
    for place in places:
        fields = []
        fields.append("fun:")
        fields.append(fun)
        fields.append("file:")
        fields.append(place.file)
        fields.append("line:")
        fields.append(place.line)
        fields.append("column:")
        fields.append(int(place.column) + 1)
        sys.stderr.write("\n".join())
        sys.stderr.write("\n")
        c.execute("""update positions
set static=1
where function = ?
      and source_file = ?
      and line = ?
      and column = ?""",
                  (fun, place.file, place.line, int(place.column) + 1)
                 )

@void_single_function_call@
identifier caller, input, work;
type input_type;
position pos;
@@
 void caller at pos(input_type input)
 {
(
  work(input);
|
  work(input);
  return;
)
 }

@script:python void_collection depends on void_single_function_call@
typ << void_single_function_call.input_type;
fun << void_single_function_call.caller;
point << void_single_function_call.input;
places << void_single_function_call.pos;
@@
store_positions(fun, typ, point, places)

@non_void_single_function_call@
identifier caller, input, result, work;
type data_type, input_type, return_type;
position pos;
@@
 return_type caller at pos(input_type input)
 {
(
  return work(input);
|
  data_type result = work(input);
  return result;
)
 }

@script:python non_void_collection depends on non_void_single_function_call@
typ << non_void_single_function_call.data_type;
fun << non_void_single_function_call.caller;
point << non_void_single_function_call.input;
places << non_void_single_function_call.pos;
@@
store_positions(fun, typ, point, places)

@void_find_static depends on void_single_function_call@
identifier void_single_function_call.caller;
position void_single_function_call.pos;
@@
 static void callerk at pos(...)
 {
  ...
 }

@non_void_find_static depends on non_void_single_function_call@
identifier non_void_single_function_call.caller;
type non_void_single_function_call.return_type;
position non_void_single_function_call.pos;
@@
 static return_type callerk@pos(...)
 {
  ...
 }

@script:python index_creation@
@@
if build_index:
   c.execute("""
create unique index x
on positions(function, source_file, line, column)""")
   build_index=False

@script:python void_addition depends on void_find_static@
fun << void_single_function_call.caller;
places << void_single_function_call.pos;
@@
store_static(fun, places)

@script:python non_void_addition depends on non_void_find_static@
fun << non_void_single_function_call.caller;
places << non_void_single_function_call.pos;
@@
store_static(fun, places)

@finalize:python@
@@
c.execute("select count(*) nr from positions")
entry = c.fetchone()

if entry[0] > 0:
   c.execute("""
select *
from positions
order by source_file, function, line, column""")
   mark1 = ['"', '', '"']
   mark2 = ['"', '', '"']
   delimiter = '|'
   sys.stdout.write(delimiter.join(("static",
                                    "function",
                                    '"data type"',
                                    '"parameter"',
                                    '"source file"',
                                    "line",
                                    "column"
                                   )))
   sys.stdout.write("\r\n")
   for entry in c:
      mark1[1] = entry[2]
      mark2[1] = entry[4].replace('"', '""')
      sys.stdout.write(delimiter.join((str(entry[0]),
                                       entry[1],
                                       ''.join(mark1),
                                       entry[3],
                                       ''.join(mark2),
                                       str(entry[5]),
                                       str(entry[6])
                                      )))
      sys.stdout.write("\r\n")
else:
   sys.stderr.write("No result for this analysis!\n")

connection.close()
-------------- next part --------------
@initialize:python@
@@
import sys
import sqlite3 as SQLite
connection = SQLite.connect(":memory:")
c = connection.cursor()
c.execute("""
create table positions
(static integer default 0,
 function text,
 data_type text,
 parameter text,
 source_file text,
 line integer,
 column integer,
 constraint c
 primary key (function, source_file, line, column)
)
without rowid""")
build_index=True

def store_positions(fun, typ, point, places):
    """Add source code positions to an internal list."""
    for place in places:
        c.execute("""insert into positions
(function,
 data_type,
 parameter,
 source_file,
 line,
 column
)
values (?, ?, ?, ?, ?, ?)""",
                  (fun,
                  typ,
                  point,
                  place.file,
                  place.line,
                  int(place.column) + 1
                  )
                 )

def store_static(fun, places):
    """Record that a function is static."""
    for place in places:
        c.execute("""update positions
set static=1
where function = ?
      and source_file = ?
      and line = ?
      and column = ?""",
                  (fun, place.file, place.line, int(place.column) + 1)
                 )

@single_function_call@
identifier caller, input, result, work;
type data_type, input_type, return_type;
position pos;
@@
 return_type caller at pos(input_type input)
 {
(
  work(input);
|
  return work(input);
|
  data_type result = work(input);
  return result;
|
  work(input);
  return;
)
 }

@script:python collection depends on single_function_call@
typ << single_function_call.input_type;
fun << single_function_call.caller;
point << single_function_call.input;
places << single_function_call.pos;
@@
store_positions(fun, typ, point, places)

@find_static depends on single_function_call@
identifier single_function_call.caller;
type single_function_call.return_type;
position single_function_call.pos;
@@
 static return_type callerk@pos(...)
 {
  ...
 }

@script:python index_creation@
@@
if build_index:
   c.execute("""
create unique index x
on positions(function, source_file, line, column)""")
   build_index=False

@script:python addition depends on find_static@
fun << single_function_call.caller;
places << single_function_call.pos;
@@
store_static(fun, places)

@finalize:python@
@@
c.execute("select count(*) nr from positions")
entry = c.fetchone()

if entry[0] > 0:
   c.execute("""
select *
from positions
order by source_file, function, line, column""")
   mark1 = ['"', '', '"']
   mark2 = ['"', '', '"']
   delimiter = '|'
   sys.stdout.write(delimiter.join(("static",
                                    "function",
                                    '"data type"',
                                    '"parameter"',
                                    '"source file"',
                                    "line",
                                    "column"
                                   )))
   sys.stdout.write("\r\n")
   for entry in c:
      mark1[1] = entry[2]
      mark2[1] = entry[4].replace('"', '""')
      sys.stdout.write(delimiter.join((str(entry[0]),
                                       entry[1],
                                       ''.join(mark1),
                                       entry[3],
                                       ''.join(mark2),
                                       str(entry[5]),
                                       str(entry[6])
                                      )))
      sys.stdout.write("\r\n")
else:
   sys.stderr.write("No result for this analysis!\n")

connection.close()

[Cocci] Finding function implementations that call only a single function.

[SF Markus Elfring]

>> I hope that a log format selection does not block a constructive dialogue
>> for the clarification of interesting SmPL rules.
> 
> Sorry but it does.

If you insist on a log file format in this way, you can also get it.
How should your preferred log format look exactly?


> I won't look at it further until there is only one SmPL file, it contains 
> a small numnber of rules,

I am going try again to inform you about software development progress in smaller steps.


> there is a small C file,

I attached one that contains the function implementations that should be found
with another semantic patch approach.


> and there is a high level description of what you expect.

I expect the following list of properties for four functions after the selection
of a single source file for a data extraction.

They fit to the filter criterium that only a single function is called within
their implementations.


>>>> static|function|"data type"|"parameter"|"source file"|line|column
>>>> 1|ast_ttm_mem_global_init|"struct drm_global_reference"|ref|"/usr/src/linux-stable/drivers/gpu/drm/ast/ast_ttm.c"|39|1
>>>> 1|ast_ttm_mem_global_release|"struct drm_global_reference"|ref|"/usr/src/linux-stable/drivers/gpu/drm/ast/ast_ttm.c"|45|1
>>>> 1|ast_ttm_tt_populate|"struct ttm_tt *"|ttm|"/usr/src/linux-stable/drivers/gpu/drm/ast/ast_ttm.c"|228|12
>>>> 1|ast_ttm_tt_unpopulate|"struct ttm_tt *"|ttm|"/usr/src/linux-stable/drivers/gpu/drm/ast/ast_ttm.c"|233|13
> 
> How much of this output is actually relevant to your problem?

This the expected result in principle.


> For example, you ask me to work on a specific file.

Yes. - I find it appropriate for further tests.


> So why does the output have to contain the file name.

The file name should be copied from the source code position metavariables
to the desired list display.


> Why does the output need to contain the parameter name, etc.

The involved data type should be directly seen from the function signature.


> All that it needs is the function name and the line number,

The text column is also needed to make a found source code position unique.


> because there might be more than one function with the same name.

Yes. - Functions are also occasionally redefined because of conditional compilation.


> The rest is noise and unreadable
> - there are no space, there are lots of quotes, there sre more than 80 columns, etc.

Would you like to introduce another coding style convention?


> I can only help you with something that is matched but should not be,
> or something that is not matched but should be.

I hope that we can keep our dialogue constructive on such issue improvements.


It seems that we can eventually clarify a part of my observations (without additional
logging) already from a SmPL pattern like the following.

@single_function_call@
identifier caller, input, work;
type input_type, return_type;
@@
*return_type caller(input_type input)
 {
(
  work(input);
|
  return work(input);
)
 }

@single_function_call_with_pointer@
identifier caller, element, input, work;
type input_type, return_type;
@@
*return_type caller(input_type * input)
 {
(
  work(input->element);
|
  return work(input->element);
)
 }


elfring at Sonne:~/Projekte/Coccinelle/Probe> spatch.opt -sp-file find_single_function_call1.cocci ast_ttm-excerpt1.c
init_defs_builtins: /usr/local/share/coccinelle/standard.h
HANDLING: ast_ttm-excerpt1.c
diff = 
--- ast_ttm-excerpt1.c
+++ /tmp/cocci-output-19572-537bbf-ast_ttm-excerpt1.c
@@ -25,24 +25,18 @@
 /*
  * Authors: Dave Airlie <airlied@redhat.com>
  */
-static int
-ast_ttm_mem_global_init(struct drm_global_reference *ref)
 {
        return ttm_mem_global_init(ref->object);
 }
 
-static void
-ast_ttm_mem_global_release(struct drm_global_reference *ref)
 {
        ttm_mem_global_release(ref->object);
 }
 
-static int ast_ttm_tt_populate(struct ttm_tt *ttm)
 {
        return ttm_pool_populate(ttm);
 }
 
-static void ast_ttm_tt_unpopulate(struct ttm_tt *ttm)
 {
        ttm_pool_unpopulate(ttm);
 }



One of my concerns here is the influence of the function return type
on the SmPL evaluation speed so that more fine-tuning will be appropriate
for the filter patterns.

Regards,
Markus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ast_ttm-excerpt1.c
Type: text/x-csrc
Size: 1631 bytes
Desc: not available
URL: <https://systeme.lip6.fr/pipermail/cocci/attachments/20141207/6a30a4e1/attachment.bin>

[Cocci] Finding function implementations that call only a single function.

[Julia Lawall]

OK, now the C file is manageable, if I drop the 20 lines of comments at 
the top of the file.

The following is also a completely understandable semantic patch:

> @single_function_call@
> identifier caller, input, work;
> type input_type, return_type;
> @@
> *return_type caller(input_type input)
>  {
> (
>   work(input);
> |
>   return work(input);
> )
>  }
> 
> @single_function_call_with_pointer@
> identifier caller, element, input, work;
> type input_type, return_type;
> @@
> *return_type caller(input_type * input)
>  {
> (
>   work(input->element);
> |
>   return work(input->element);
> )
>  }

So, now what is the problem with the following output?

> elfring at Sonne:~/Projekte/Coccinelle/Probe> spatch.opt -sp-file find_single_function_call1.cocci ast_ttm-excerpt1.c
> init_defs_builtins: /usr/local/share/coccinelle/standard.h
> HANDLING: ast_ttm-excerpt1.c
> diff = 
> --- ast_ttm-excerpt1.c
> +++ /tmp/cocci-output-19572-537bbf-ast_ttm-excerpt1.c
> @@ -25,24 +25,18 @@
>  /*
>   * Authors: Dave Airlie <airlied@redhat.com>
>   */
> -static int
> -ast_ttm_mem_global_init(struct drm_global_reference *ref)
>  {
>         return ttm_mem_global_init(ref->object);
>  }
>  
> -static void
> -ast_ttm_mem_global_release(struct drm_global_reference *ref)
>  {
>         ttm_mem_global_release(ref->object);
>  }
>  
> -static int ast_ttm_tt_populate(struct ttm_tt *ttm)
>  {
>         return ttm_pool_populate(ttm);
>  }
>  
> -static void ast_ttm_tt_unpopulate(struct ttm_tt *ttm)
>  {
>         ttm_pool_unpopulate(ttm);
>  }
> 
> 
> 
> One of my concerns here is the influence of the function return type
> on the SmPL evaluation speed so that more fine-tuning will be appropriate
> for the filter patterns.

Worrying about the speed of matching of a couple of tokens is completely 
pointless.  If you want to see that in practice, just use the --profile 
option and see what is the time with and without the matching you are 
concerned about.  Unless your pattern requires following a lot of 
different control-flow paths, eg due to sequences of conditionals, the C 
code parsing time will massively dominate the matching time.

julia

[Cocci] Finding function implementations that call only a single function.

[SF Markus Elfring]

> OK, now the C file is manageable, if I drop the 20 lines of comments at 
> the top of the file.
> 
> The following is also a completely understandable semantic patch:
> 
>> @single_function_call@
>> identifier caller, input, work;
>> type input_type, return_type;
>> @@
>> *return_type caller(input_type input)
>>  {
>> (
>>   work(input);
>> |
>>   return work(input);
>> )
>>  }
>>
>> @single_function_call_with_pointer@
>> identifier caller, element, input, work;
>> type input_type, return_type;
>> @@
>> *return_type caller(input_type * input)
>>  {
>> (
>>   work(input->element);
>> |
>>   return work(input->element);
>> )
>>  }
> 
> So, now what is the problem with the following output?

The source code output is not the problem from the application
of such a small SmPL script.

I find that my filter patterns contain open issues here.

One part of each SmPL disjunction will always not match in this approach
if an analysed function implementation has got the return type "void".
Would the specification of a metavariable "return_type" be also
unnecessary and inappropriate in this use case?


>> One of my concerns here is the influence of the function return type
>> on the SmPL evaluation speed so that more fine-tuning will be appropriate
>> for the filter patterns.
> 
> Worrying about the speed of matching of a couple of tokens is completely pointless.

I guess that this view will need adjustments if I am going to rerun
an extended version of the shown SmPL example on all Linux source files
as it happened for a couple of clean-ups around unnecessary (pointer) checks.


> If you want to see that in practice, just use the --profile 
> option and see what is the time with and without the matching you are 
> concerned about.

I might try that out more in the near future.


> Unless your pattern requires following a lot of different control-flow paths,
> eg due to sequences of conditionals, the C code parsing time will massively
> dominate the matching time.

The Coccinelle software has got difficulties with specific Linux source files
so that it became safer to add the command line parameter "timeout" for example.

I can only directly influence the SmPL scripts here. So I try to make them as good
and fast as I can. Other technical improvements will eventually need more efforts.

Regards,
Markus

[Cocci] Finding function implementations that call only a single function.

[Julia Lawall]

On Sun, 7 Dec 2014, SF Markus Elfring wrote:

> > OK, now the C file is manageable, if I drop the 20 lines of comments at 
> > the top of the file.
> > 
> > The following is also a completely understandable semantic patch:
> > 
> >> @single_function_call@
> >> identifier caller, input, work;
> >> type input_type, return_type;
> >> @@
> >> *return_type caller(input_type input)
> >>  {
> >> (
> >>   work(input);
> >> |
> >>   return work(input);
> >> )
> >>  }
> >>
> >> @single_function_call_with_pointer@
> >> identifier caller, element, input, work;
> >> type input_type, return_type;
> >> @@
> >> *return_type caller(input_type * input)
> >>  {
> >> (
> >>   work(input->element);
> >> |
> >>   return work(input->element);
> >> )
> >>  }
> > 
> > So, now what is the problem with the following output?
> 
> The source code output is not the problem from the application
> of such a small SmPL script.
> 
> I find that my filter patterns contain open issues here.
> 
> One part of each SmPL disjunction will always not match in this approach
> if an analysed function implementation has got the return type "void".
> Would the specification of a metavariable "return_type" be also
> unnecessary and inappropriate in this use case?

Currently, return_type does absolutely nothing.  You can just drop it.

> > Unless your pattern requires following a lot of different control-flow paths,
> > eg due to sequences of conditionals, the C code parsing time will massively
> > dominate the matching time.
> 
> The Coccinelle software has got difficulties with specific Linux source files
> so that it became safer to add the command line parameter "timeout" for example.
> 
> I can only directly influence the SmPL scripts here. So I try to make them as good
> and fast as I can. Other technical improvements will eventually need more efforts.

The changes you are considering will have no impact on whether timeout is 
needed.  If something requires eg 2000 seconds to complete, dropping 1 2 
or 100 seconds will have no noticible impact.

julia

[Cocci] Finding function implementations that call only a single function.

[SF Markus Elfring]

>> One part of each SmPL disjunction will always not match in this approach
>> if an analysed function implementation has got the return type "void".
>> Would the specification of a metavariable "return_type" be also
>> unnecessary and inappropriate in this use case?
> 
> Currently, return_type does absolutely nothing.  You can just drop it.

Should I really omit to distinguish the function return type?

When should a filter pattern on function implementations be adapted to
the property that there will be a return value affected (or not)?

Regards,
Markus

[Cocci] Finding function implementations that call only a single function.

[Julia Lawall]

On Sun, 7 Dec 2014, SF Markus Elfring wrote:

> >> One part of each SmPL disjunction will always not match in this approach
> >> if an analysed function implementation has got the return type "void".
> >> Would the specification of a metavariable "return_type" be also
> >> unnecessary and inappropriate in this use case?
> > 
> > Currently, return_type does absolutely nothing.  You can just drop it.
> 
> Should I really omit to distinguish the function return type?

If the return type has no impact on the match, it can be omitted.

> When should a filter pattern on function implementations be adapted to
> the property that there will be a return value affected (or not)?

I don't understand the question.

julia

[Cocci] Finding function implementations that call only a single function.

[SF Markus Elfring]

> If the return type has no impact on the match, it can be omitted.

Is another metavariable needed to filter on functions with a non-void
return type?


>> When should a filter pattern on function implementations be adapted to
>> the property that there will be a return value affected (or not)?
> 
> I don't understand the question.

It seems that I need to describe my small SmPL example with more
drastic words. Would it introduce programming errrors in such an
application of the semantic patch language?

Does it contain logical mistakes?

Regards,
Markus

[Cocci] Finding function implementations that call only a single function.

[Julia Lawall]

On Sun, 7 Dec 2014, SF Markus Elfring wrote:

> > If the return type has no impact on the match, it can be omitted.
> 
> Is another metavariable needed to filter on functions with a non-void
> return type?

I already explained how this should be done.  Match the functions that 
have a void return type, record their positions, and then match the 
functions at other positions.  The first set have void type, the second do 
not.

Of course, you can also tell from the returns, or lack there of, in the 
function whether the function has void return type as well.

julia

> 
> 
> >> When should a filter pattern on function implementations be adapted to
> >> the property that there will be a return value affected (or not)?
> > 
> > I don't understand the question.
> 
> It seems that I need to describe my small SmPL example with more
> drastic words. Would it introduce programming errrors in such an
> application of the semantic patch language?
> 
> Does it contain logical mistakes?
> 
> Regards,
> Markus
> 

[Cocci] Finding function implementations that call only a single function.

[SF Markus Elfring]

> Of course, you can also tell from the returns, or lack there of, in the 
> function whether the function has void return type as well.

This approach is exactly the kind of SmPL filter design I tried out
with the script "list_functions_with_single_function_call5-no_db.cocci"
for example.

Unfortunately, I frightened and annoyed you with that SmPL rule collection
to some degree.

I suggest to reconsider this situation once more.
* It can be that I got stuck somehow in this application variant as the
  number of relevant rules grew.

* But is it also possible to compute the number of required rules from
  factors in this way for a logically correct version?
  return_type_detection x pointer_usage x static_determination x ...

Regards,
Markus

[Cocci] Finding function implementations that call only a single function.

[SF Markus Elfring]

> I suggest to reconsider this situation once more.

I have looked at my script "list_functions_with_single_function_call5.cocci" again.


> * It can be that I got stuck somehow in this application variant as the
>   number of relevant rules grew.

It seems that I made a bit progress in a better direction.

Now I stumble on the next detail problem if I try to design the needed
SmPL rules for more specific source code.

* How can it be excluded with the semantic patch language to match non-pointer
  data types with the metavariable type "type?"
* Which is the best way to distinguish non-pointer types from pointer data types
  with metavariables?


Regards,
Markus

[Cocci] Finding function implementations that call only a single function.

[Julia Lawall]

On Wed, 17 Dec 2014, SF Markus Elfring wrote:

> > I suggest to reconsider this situation once more.
>
> I have looked at my script "list_functions_with_single_function_call5.cocci" again.
>
>
> > * It can be that I got stuck somehow in this application variant as the
> >   number of relevant rules grew.
>
> It seems that I made a bit progress in a better direction.
>
> Now I stumble on the next detail problem if I try to design the needed
> SmPL rules for more specific source code.
>
> * How can it be excluded with the semantic patch language to match non-pointer
>   data types with the metavariable type "type?"
> * Which is the best way to distinguish non-pointer types from pointer data types
>   with metavariables?

If you do the following:

@@
expression * e1;
expression e2;
@@

(
e1
|
e2
)

Then e2 should match the non-pointer type expressions.

julia

[Cocci] Distinguishing pointer data types with SmPL

[SF Markus Elfring]

>> * Which is the best way to distinguish non-pointer types from pointer data types
>>   with metavariables?
> 
> If you do the following:
> 
> @@
> expression * e1;
> expression e2;
> @@
> 
> (
> e1
> |
> e2
> )
> 
> Then e2 should match the non-pointer type expressions.

Is it relevant if you use "expression" or "type" here?


I guess that my previous use case was a bit different because the pointer
distinction was distributed over function parameters in separate SmPL rules.

I got the impression that a single metavariable with the SmPL type "type"
might be insufficient for a selection if the asterisk is omitted there.
Does the filter approach need to be disambiguated with additional criteria
like variable constraints or a part from the function implementation?

Regards,
Markus