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

[elfring@users.sourceforge.net (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>