Change draft for #80 (codeFlows)

I pushed a change draft for Issue #80: Code flow enhancements

There are two substantive changes:

Better support for multiple threads

Previously, a codeFlow object contained an array of annotatedCodeLocation objects. You could indicate multiple threads by marking each annotatedCodeLocation with a threadId.

Now, a codeFlow object contains an array of threadFlow objects. A threadFlow represents a single thread of execution, such as an operating system thread or a fiber. A threadFlow contains an id (like a thread id) and an array of annotatedCodeLocation objects. In the Change Draft, you’ll see that I basically renamed codeFlow to threadFlow, and then introduced a new codeFlow type to wrap the threadFlows.
Concentrate on viewer support

Previously, a codeFlow object contained a set of properties (kind, target, values, and taintKind) that attempted to capture the semantics of each location (possibly for examination by automated tools). Per discussion in the face-to-face meeting, we’ve refocused the code flow feature to support the viewing experience, and abandoned the attempt to capture semantics. We removed the kind, target, values, and taintKind properties.

A viewer can always provide a user-facing message that captures what those properties used to represent, together with embedded links, for example: “Tainted data entered the system [here](2)”.

I’ll move to adopt this change at the TC meeting on Wednesday.

Thanks,

Larry

sarif message