OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

sarif message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Change draft for #80 (codeFlows)

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




There are two substantive changes:


  1. 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.

  2. 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.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]