Hi,
There is a whole class of false positives, which I believe the reward is great, if it is solved.
Occurs for example, with the lua code (https://github.com/lua/lua)
If there is an error function, which does not return at all,
confuses cppcheck in several alerts.
For example division by zero.
Attached, two simple examples, but which is occurring, when analyzing the lua code, reports a false positive by division by zero.
you can tell Cppcheck that your "ferror" does not return;
* you can annotate your "ferror" function and say that it does not return. Such annotation could help other tools also.
* you can provide a cppcheck configuration for "ferror". See: http://cppcheck.sourceforge.net/manual.html#library-configuration
But well in general the Cppcheck philosophy is that if there is missing configuration then false positives should be avoided. The user can reduce false negatives with configuration. This approach is documented in our "cppcheck-philosophy.md" document. And here we do not follow that philosophy. Well it could be discussed what we should do here in this case..
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry, by bad name choice, ferror is own yes, could be own_error name.
Happy to know, about tell Cppcheck, that error function does not return.
I think this is a solution, for these false-positives.
Is very hard to guess, when error funciton does not return, the lua code is very complex.
I believe that actual Cppcheck philosophy is correct, exist thousands functions in source code,
and is hard to guess, what is correct or not, the user must be help with configuration.
Thank you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
There is a whole class of false positives, which I believe the reward is great, if it is solved.
Occurs for example, with the lua code (https://github.com/lua/lua)
If there is an error function, which does not return at all,
confuses cppcheck in several alerts.
For example division by zero.
Attached, two simple examples, but which is occurring, when analyzing the lua code, reports a false positive by division by zero.
regards,
Ranier Vilela
so I guess ferror is their own function. The standard "ferror" function returns:
http://www.cplusplus.com/reference/cstdio/ferror/
you can tell Cppcheck that your "ferror" does not return;
* you can annotate your "ferror" function and say that it does not return. Such annotation could help other tools also.
* you can provide a cppcheck configuration for "ferror". See: http://cppcheck.sourceforge.net/manual.html#library-configuration
But well in general the Cppcheck philosophy is that if there is missing configuration then false positives should be avoided. The user can reduce false negatives with configuration. This approach is documented in our "cppcheck-philosophy.md" document. And here we do not follow that philosophy. Well it could be discussed what we should do here in this case..
Sorry, by bad name choice, ferror is own yes, could be own_error name.
Happy to know, about tell Cppcheck, that error function does not return.
I think this is a solution, for these false-positives.
Is very hard to guess, when error funciton does not return, the lua code is very complex.
I believe that actual Cppcheck philosophy is correct, exist thousands functions in source code,
and is hard to guess, what is correct or not, the user must be help with configuration.
Thank you.