On Tue, 27 Dec 2011, SF Markus Elfring wrote:
It is better, but things like return "surprise" return 1 and return a + a
contribute nothing to the understanding of the example.
I tried to show a few slightly meaningful function implementations in my
source code example.
If it is not helpful to solve the problem, then it is not useful to
include in the email. The purpose is not to demonstrate good programming
style. The purpose is to communicate information about whatever problem
you are having in using the tool.
The function prototypes for example are also not useful.
I have a small screen. It is easiest if I can see everything related to the
example in say 20 lines.
I could also adhere to such a limit easily if I would change the used coding
style drastically. ;-)
Do you mind if I would use a dense reformatting like each function on one
line completely? (Are the following nine lines acceptable for further
checks?)
No, it is completely unreadable.
elfring@Sonne:~/Projekte/Coccinelle/lokal/demos/return_values>
SRC=example1b.c && cat $SRC && LINE='-----' && echo $LINE &&
PAT=select_non_void_functions.cocci && cat $PAT && echo $LINE && spatch
-sp_file $PAT $SRC
int my_safe_log(char const * text);
int my_status(void);
void my_log(char const * text) {/* Write something ... */}
int my_safe_log(char const * text) { if (!text) return 1; my_log(text);
return 0; }
char const * const my_message(void) { return "Surprise!"; }
int my_status(void) { return 1; }
int my_addition(char a, char b);
int my_addition(char a, char b) { return a + b; }
int main(void) { return my_status(); }
-----
@initialize:python@
result = []
delimiter = '|'
@function_declaration@
identifier f;
position p;
@@
f@p(...);
@is_void@
identifier function_declaration.f;
@@
void f(...);
@script:python collection depends on !is_void@
fun << function_declaration.f;
places << function_declaration.p;
@@
for place in places:
fields = []
fields.append(fun.ident)
fields.append(place.file)
fields.append(place.line)
fields.append(place.column)
result.append(delimiter.join(fields))
@finalize:python@
if result:
result.insert(0, delimiter.join(("function", "source file", "line",
"column")))
print("\r\n".join(result))
else:
print("No result for this analysis!")
-----
init_defs_builtins: /usr/share/coccinelle/standard.h
HANDLING: example1b.c
function|source file|line|column
my_log|example1b.c|4|58
I would expect that the functions "my_safe_log", "my_status" and
"my_addition"
will be displayed together with their attributes in the test result.
Would you like to suggest any more adjustments?
You only print out information about functions that are called
(function_definition.f).
I do not see that in my SmPL filter pattern now. I would like to extend it in
this direction that the use case will be displayed in my export file format
when a function was declared and if it is defined/implemented at one place.
All of your rules refer to function_definition.f. function_definition.f
is only bound when a function is called. In the case of python, if any
of the inherited variables is not bound, then the python code is not
executed. This is the case even if the unbound variable is not mentioned
in the python code.
As far as I can see, my_addition is never called.
That's right for this source code example.
Your rule only prints information about functions that are called. So it
will not print information about my_addition. I don't know what criteria
you want to use to cause my_addition to be printed.
julia
_______________________________________________
Cocci mailing list
[email protected]
http://lists.diku.dk/mailman/listinfo/cocci
(Web access from inside DIKUs LAN only)
