`RULE-25-21`, others: Consider something like a library TracesToExplicit<T>
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
Research direction
Start by examining the implementation and tests for RULE-25-21 and the handling of atomic_*_explicit operations. Define the supported backwards-tracking cases for assignments, parameters, and function calls or returns, then determine how invalid paths should be reported. Done means the proposed tracing library handles acceptable roots and rejects values that cannot be traced to memory_order_seq_cst.
Written by the indexing model from the issue text.
Description
Affected rules
RULE-25-21- Likely others, haven't researched
Description
Rule 25-21 requires that the atomic_*_explicit operations use the memory order memory_order_seq_cst.
It would probably be overly restrictive to require an explicit inline written memory_order_seq_cst at the call site. However, it's probably too accepting to merely allow any dynamically computed value. Ideally, we can support basic indirection like variable assignment, parameter values, function calls/returns, and report cases that don't trace back to an acceptable root.
Doing this as a typical flow analysis is backwards. We can easily track flow from memory_order_seq_cst exprs to atomic_*_explicit calls, but the existence of such a flow doesn't preclude that invalid values also flow to the call. Alternatively, there are potential performance issues if we consider all exprs which are not memory_order_seq_cst to be sources in the flow analysis.
Wouldn't be terribly hard to write a library such as TracesToExplicit<T> that is a very simple global flow analysis made for this purpose, starting from sinks and doing only very obvious backwards tracking of values through function calls and variable assignments. If that doesn't track back to an acceptable value, we can report it. Ideally we can report it as a path-problem though this makes such a library more complex to implement.
- 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
-
Difficulty-Medium false positive/false negative false-positive Impact-Medium Standard-CERT-C
Difficulty 4/5 3-5 days Newbie friendliness 48/100
github/codeql-coding-standards#1200 ·
-
`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 ·
All issues in github/codeql-coding-standards
Similar issues
-
ZCode 3.14.3 に対応する Open
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
supermomonga/zcode-acp#24 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
learningequality/ricecooker#747 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
KhronosGroup/glTF-Blender-IO#2769 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100