hohn/codeql
1
0
Fork 0
mirror of https://github.com/github/codeql.git synced 2025-12-16 16:53:25 +01:00
Code Issues Packages Projects Releases Wiki Activity

Rephrase change note to avoid technical terms

Browse Source
This commit is contained in:
Owen Mansel-Chan
2025-09-25 12:53:55 +01:00
parent 630a8446ad
commit 7b426186aa
1 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
go/ql/lib/change-notes/2025-09-19-use-use-flow-proper-post-update-nodes.md
View File

@@ -1,4 +1,4 @@
---
category: majorAnalysis
---
* Previously, data flow used def-use flow and a node's post-update node was either its definition or the node itself. This caused some problems with false positives caused by steps backwards from a node to its definition. Now, data flow has been changed to use-use flow with proper post-update nodes. This should improve accuracy and reduce false positives in the analysis. The main effect on queries is that sanitization works differently - if you sanitize a node then flow will not reach any uses after the sanitized node. Where this is not desired it maybe be necessary to add an additional flow step to propagate the flow forward.
* The shape of the Go data-flow graph has changed. Previously for code like `x := def(); use1(x); use2(x)`, there would be edges from the definition of `x` to each use. Now there is an edge from the definition to the first use, then another from the first use to the second, and so on. This means that data-flow barriers work differently - flow will not reach any uses after the barrier node. Where this is not desired it may be be necessary to add an additional flow step to propagate the flow forward. Additionally, when a variable may be subject to a side-effect, such as updating an array, passing a pointer to a function that might write through it or writing to a field of a struct, there is now a dedicated post-update node representing the variable after this side-effect has taken place. Previously post-update nodes were aliases for either a variable's definition, or were equal to the pre-update node. This led to backwards steps in the data-flow graph, which could cause false positives. For example, in the previous code there would be an edge from `x` in `use2(x)` back to the definition of `x`. If we define our sources as any argument of `use2` and our sinks as any argument of `use1` then this would lead to a false positive path. Now there are distinct post-update nodes and no backwards edge to the definition, so we will not find this false positive path.