It turns out that the bminor/bash alert spewage was caused by

a bug in the extractor, which is verified fixed in the next release.
Reverting query to its original form.
This commit is contained in:
Ziemowit Laski
2019-07-08 12:11:15 -07:00
parent 07ee9be9b6
commit ed5e2f3211
2 changed files with 2 additions and 3 deletions

View File

@@ -5,7 +5,7 @@
* that the code does not follow the author's intent. * that the code does not follow the author's intent.
* @kind problem * @kind problem
* @problem.severity warning * @problem.severity warning
* @precision high * @precision very-high
* @id cpp/futile-params * @id cpp/futile-params
* @tags correctness * @tags correctness
* maintainability * maintainability
@@ -34,7 +34,6 @@ predicate isCompiledAsC(Function f) {
from FunctionCall fc, Function f from FunctionCall fc, Function f
where where
f = fc.getTarget() and f = fc.getTarget() and
f.getNumberOfParameters() = 0 and
not f.isVarargs() and not f.isVarargs() and
hasZeroParamDecl(f) and hasZeroParamDecl(f) and
isCompiledAsC(f) and isCompiledAsC(f) and

View File

@@ -38,7 +38,7 @@ void test(int *argv[]) {
int x; int x;
declared_empty_defined_with(&x); // BAD declared_empty_defined_with(&x); // BAD
declared_empty_defined_with(3, &x); // BAD [NOT DETECTED] declared_empty_defined_with(3, &x); // BAD
not_declared_defined_with(-1, 0, 2U); // GOOD not_declared_defined_with(-1, 0, 2U); // GOOD
not_declared_defined_with(4LL, 0, 2.5e9f); // BAD not_declared_defined_with(4LL, 0, 2.5e9f); // BAD