diff --git a/man/buildman.sh b/man/buildman.sh index e98981f2c..3f9f39a83 100755 --- a/man/buildman.sh +++ b/man/buildman.sh @@ -5,6 +5,12 @@ xsltproc -o manual.html /usr/share/xml/docbook/stylesheet/nwalsh/xhtml/docbook.x xsltproc -o intermediate-fo-file.fo /usr/share/xml/docbook/stylesheet/nwalsh/fo/docbook.xsl manual.docbook fop -pdf manual.pdf -fo intermediate-fo-file.fo -xsltproc --stringparam generate.toc "article nop" -o intermediate-fo-file.fo /usr/share/xml/docbook/stylesheet/nwalsh/fo/docbook.xsl writing-rules.docbook -fop -pdf writing-rules.pdf -fo intermediate-fo-file.fo +xsltproc --stringparam generate.toc "article nop" -o intermediate-fo-file.fo /usr/share/xml/docbook/stylesheet/nwalsh/fo/docbook.xsl writing-rules-1.docbook +fop -pdf writing-rules-1.pdf -fo intermediate-fo-file.fo + +xsltproc --stringparam generate.toc "article nop" -o intermediate-fo-file.fo /usr/share/xml/docbook/stylesheet/nwalsh/fo/docbook.xsl writing-rules-2.docbook +fop -pdf writing-rules-2.pdf -fo intermediate-fo-file.fo + +xsltproc --stringparam generate.toc "article nop" -o intermediate-fo-file.fo /usr/share/xml/docbook/stylesheet/nwalsh/fo/docbook.xsl cppcheck-design.docbook +fop -pdf cppcheck-design.pdf -fo intermediate-fo-file.fo diff --git a/man/cppcheck-design-overview.docbook b/man/cppcheck-design.docbook similarity index 62% rename from man/cppcheck-design-overview.docbook rename to man/cppcheck-design.docbook index d5daf3781..f55c4f1f9 100644 --- a/man/cppcheck-design-overview.docbook +++ b/man/cppcheck-design.docbook @@ -7,7 +7,7 @@ xmlns:html="http://www.w3.org/1999/xhtml" xmlns:db="http://docbook.org/ns/docbook"> - Cppcheck Design Overview + Cppcheck Design DanielMarjamäki @@ -23,63 +23,49 @@
Introduction - This article is an overview of the design of Cppcheck. + This article contains an overview of how Cppcheck works. - The design of Cppcheck are based on: + The primary goal is that Cppcheck won't write any false warnings. + This means that when an error is reported there must definitely be a bug + in the code. - - - Cppcheck will never be perfectly clever - - - - No false warnings are allowed - - + The secondary goal is to detect as many bugs as possible.
Limitations of static analysis - It is not very reasonable to think that a static analysis tool will - detect all bugs in your code. + There are many bugs in programs that are really hard to detect for + tools. Here is an example: - There are many bugs in programs that is really hard to detect for - tools. - - Many bugs are caused by wrong calculations. Here is an - example: - - // calculate number of days + // calculate the number of days int days(int hours) { return hours / 23; } - A human programmer can see the error in that code because he knows + A human programmer knows that there are 24 hours in a day and + therefore he could see that "23" is wrong. A tool will probably not know that there are 24 hours in a day. - Tools will probably not know that there are 24 hours in a - day. - A tool that tries to guarantee that all bugs are found could write a - warning message for every calculation in the program. In my humble opinion - it wouldn't be usable to do that. + warning message for every "suspicious" calculation in the program. It + might correctly report that "hours / 23" is wrong but incorrectly warn + about "hours / 24". Cppcheck will only write a warning message if it can determine that - the calculation is wrong. This approach means that many bugs will not be - detected. + the calculation is wrong. In this case, no error will be written.
Buffer overflows - This is a simple description of the buffer overflows checking in + This is a simple description of how buffer overflows are detected by Cppcheck. - For simple cases, no sophisticated control flow analysis is used. If - an array is accessed out of bounds somewhere in its scope then an error - message will be written. + For simple cases, no control flow analysis is used. If an array is + accessed out of bounds somewhere in its scope then an error message will + be written. An example code: @@ -102,8 +88,8 @@ int days(int hours) statement is there and it has the error. Cppcheck will also investigate function calls. But then control flow - is needed to avoid false warnings. Here is an example that logically is - the same as the previous example: + analysis is needed to avoid false warnings. Here is an example that + logically is the same as the previous example: void f1(char *s) { @@ -139,7 +125,7 @@ void f2() void f2() { char a[10]; - f1(); + f1(a); }
@@ -147,9 +133,8 @@ void f2() Memory leaks Simple control-flow analysis is made. The assumtion is that all - conditions can always be either true or false. - - It is assumed that all statements are reachable. + conditions can always be either true or false. It is assumed that all + statements are reachable. Here is an example: @@ -171,8 +156,8 @@ void f2() "return;" statement. It will only see that if the execution reaches the "return;" then there will be a memory leak. - This lack of advanced control-flow analysis means that many bugs are - not detected: + Lack of advanced control-flow analysis means that many bugs are not + detected: void f(int x) { @@ -185,20 +170,21 @@ void f2() free(a); } - Many other static analysis tools will probably detect that. + Cppcheck doesn't detect any error. The "all conditions can be either + true/false" means that cppcheck doesn't know that "if (x==20)" is false + when "if (x==10)" is true. Many other static analysis tools will probably + detect that there will be a leak if x is 10. + - Many memory leaks are caused by: +
+ Final thoughts - - - Completely forgetting to deallocate - + You can not trust that Cppcheck will detect all bugs. - - Forgetting to deallocate in a bailout path - - + Cppcheck will just find some bugs. It is likely that you won't find + these bugs unless you use Cppcheck. Cppcheck has found bugs in production + code that has been used for years. - These types of leaks should be detected by Cppcheck. +