`EXP39-C`: False positives related to compatible types, harmless casts
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 48/100
Research direction
Start with the EXP39-C implementation and compare its compatibleTypes predicate with common/types/Compatible.qll, paying particular attention to typedefs and pointer compatibility. Review how casted expressions are modeled as sources and sinks, then use the provided typedef and unused-cast examples to verify that harmless casts are no longer reported.
Written by the indexing model from the issue text.
Description
Affected rules
EXP39-C
Description
First off, our implementation uses a compatibleTypes predicate that is incomplete and doesn't handle typedefs, and should be replaced with our common/types/Compatible.qll library. This results in thousands of false positives in certain codebases, usually due to casting to a project-specific typedef of a byte like GLBYTE*.
Secondly, while we use dataflow to trace realloc's that flow to a deref without a memset, we don't use dataflow to handle the more typical case of A* cast to B* followed by a deref. Instead, we have a type representing casted expressions that's both a sink and a source. (We check compatibility of the pointers in the cast in the select statement). This isn't strictly UB unless the pointer is dereferenced, and I do see examples of this in real code. As a related example, casts to void** are often flagged while void* is excluded. This isn't a rare exceptional use of void, it's really just a harmless cast.
Example
typedef char BYTE;
void example_function() {
int x;
(long *) &x; // harmless since it's unused
BYTE *x_bytes = (BYTE *)&x; // Allowed since BYTE is a char.
}
- Dominant language
- CodeQL
- Stars
- 227
- Forks
- 82
- Avg merge
- 6d 7h
- Merged PRs (30d)
- 9
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from github/codeql-coding-standards
-
false positive/false negative Stardard-MISRA-C++
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
github/codeql-coding-standards#1172 ·
-
Difficulty-Low false positive/false negative false-negative Impact-Low Standard-MISRA-C
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
`RULE-0-0-1`: "unreachable statement" false positives due to over-pruning of the control-flow graph Openfalse positive/false negative
Difficulty 4/5 3-5 days Newbie friendliness 48/100
github/codeql-coding-standards#1190 ·
-
false positive/false negative
Difficulty 3/5 1-2 days Newbie friendliness 65/100
github/codeql-coding-standards#1175 ·
-
false positive/false negative Stardard-MISRA-C++
Difficulty 3/5 1-2 days Newbie friendliness 48/100
github/codeql-coding-standards#1165 ·
All issues in github/codeql-coding-standards
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
hemilabs/ui-monorepo#2332 ·
-
Help-Wanted Needs-Triage Package-Update
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
microsoft/winget-pkgs#438662 ·
-
priority: p3
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
googleapis/librarian#7636 ·
-
bug good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
olcf/olcf-test-harness#278 · 1 comment ·