- Print "inconclusive" tag in cli
- Fixed inconclusive handling in checkbufferoverrun.cpp
- Merged reportInconclusiveError into reportError by adding an additional parameter "bool inconclusive" which is false per default
- Added support for comparision of bool constant with number constant (-> fixed#1877) and integer variable with boolean expression
- Moved a check from checkComparisonOfBoolWithInt to checkComparisonOfBoolExpressionWithInt
- Generalized some patterns
- Made error message more accurate concnerning the "neither 0 nor 1" part.
- Reduced number of Token::Match calls
- Use more generic patterns
- Look on operator precedence more consequently
-> Made a TODO test case from a test case that worked previously, because the calculation is simplified so that the problem isn't detected any more.
Changed comment "Coding style checks" to "Checks", because it didn't fit
- Bailout on expanded macros for conclusive checking
- Support for more operators
- Removed indendation counter
Improved checkSignOfUnsignedVariable:
- Made the patterns more generic
- Improved verbose error message (-> Fixed#3080)
- Added a lot of additional pattern
- Rewrote error messages to make them more understandable and better fitting to the situation. (Fixed#3664)
- Cleanup in unit tests
Improved message of static string comparision check
Fixed false negative on argument count of fnprintf/snprintf when first variable argument is a string. (#3655)
Uncommented call of virtualDestructorError in getErrorMessages in checkclass.h
Refactorizations:
- Rearranged code in checkother.h to make ordering more consistent and to increase encapsulation of private data
- Replaced some single-token-patterns
Refactorizations in checkother.cpp:
- Make use of symboldabase instead of: indentation counters, manual detection of variable declarations
- Removed some indexing variables to reduce calls to tokAt and the numbers given to this function
- Use tok->nextArgument() to jump to a specific argument
Detect sign extension problems when variable is a reference (#3637)
Refactorizations:
- Tokenizer::getFiles returns a reference instead of a pointer, because its guaranteed that no nullpointer is returned
- Remove signed/unsigned in one step for "%type% signed|unsigned"
- Fixed recently introduced compiler warning in symboldatabase.cpp
-- Use MathLib::toLongNumber for conversion in tokenizer (Fix#3610)
-- Handle octal numbers in tokenizer
- Refactorizations in MathLib::toLongNumber and Settings
- Fixed false positive: throw outerCatchVar; in inner catch is now correctly handled
- Added eTry and eCatch to Scope::isLocal -> Scopes inside catch are now detected by symbol database
Add a check for function calls that have no side effects. That means
known const methods and a list including strcmp, strlen, etc.
If the function is not known to be side effect-free then no style
warning is given.
Add test cases for the duplicate expressions.
The code branch tested by the previous check for && is now different, so
I've changed the test to use == instead. There was also a missing case
when the expression was followed by a comma instead of being preceded by
one.
Expand the logic for the check for the same expression on both sides of
the || and && operators. Now expressions can be more complex, with the
"alt" variable helping to fudge operator precedence to avoid false
positives.
This checks for the case where the user thought sizeof(buf) gave the
size in bytes of 'buf' in code like the following:
const char *buf = "Hello World";
strncmp(buf, other, sizeof(buf));
statements if they are followed by a {..} block.
Examples are:
for (int i = 0; i < 10; ++i);
{
printf("i)";
}
or
if (i == 100);
{
die("Wrong argument");
}
This new check is active if you enable inconclusive checks.
"information" severity is documented in lib/errorlogger.h as:
Checking information.
Information message about the checking (process) itself. These
messages inform about header files not found etc issues that are
not errors in the code but something user needs to know.
It IS NOT for errors in the code. All the current "information"-
severity errors fit nicely into description of the "style"-
severity.
We definitely need to separate processing information and actual
errors in the code. It is highly confusing for users to mix these
two different things. Hence all current "information" code error
messages are moved to "style" category.
Ticket: #3165 (Stop misusing the 'information' error severity!)