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: RE: [sarif] NestingLevel constraint?


When we first introduced nestingLevel, we imagined it as a direct instruction to the viewer on how far to indent. And indeed, the viewer could render the sequence [ 0, 0, 5, 5, 9, 9, 7, 7, 2, 2 ] in exactly that way:

 

Step 1

Step 2

          Step 3

          Step 4

                  Step 5

                  Step 6 (returns from funcB to funcA)

              Step 7

              Step 8 (returns from funcA to main)

  Step 9

  Step 10

 

That makes it difficult for our viewer to present the “tree view” experience it offers today. Today, since the viewer understands the caller/callee relationships between steps, it can use a tree view control, and allow the user to expand and collapse function calls.

 

A tree view can’t render the view I showed above, unless it synthesizes intermediate nodes:

 

Step 1

Step 2

  Intermediate 1

    Intermediate 2

      Intermediate 3

        Intermediate 4

          Step 3

          Step 4

            Intermediate 5

              Intermediate 6

                Intermediate 7

                  Step 5

                  Step 6 (returns from funcB to funcA)

                Intermediate 8

              Step 7

              Step 8 (returns from funcA to main)

            Intermediate 9

          Intermediate 10

        Intermediate 11

      Intermediate 12

    Intermediate 13

  Step 9

  Step 10

 

Larry

 

From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org> On Behalf Of Larry Golding (Comcast)
Sent: Friday, April 20, 2018 2:22 PM
To: sarif@lists.oasis-open.org; Michael Fanning <Michael.Fanning@microsoft.com>
Subject: [sarif] NestingLevel constraint?

 

In the old days, when we had codeFlowLocation.kind, the "call" and "callReturn" values for kind naturally forced the sequence of code flow locations into a tree structure (the call tree).

 

Now kind is gone, replaced by nestingLevel, and you can simulate the old call/return nesting by ensuring that nestingLevel either stays the same, increases by 1, or decreases by 1 between successive locations. For example, this sequence of nesting levels:

 

[ 0, 0, 1, 1, 2, 2, 1, 1, 0, 0 ]

 

… leads to a call tree like this:

 

Step 1 (in main)

Step 2 (calls funcA)

  Step 3

  Step 4 (calls funcB)

    Step 5

    Step 6 (returns from funcB to funcA)

  Step 7

  Step 8 (returns from funcA to main)

Step 9

Step 10

 

BUT! As the spec stands today, nothing stops you from creating a code flow with this sequence of nesting levels:

 

[ 0, 0, 5, 5, 9, 9, 7, 7, 2, 2 ]

 

How should we deal with that? There are three choices:

 

  1. Prohibit it in the spec. A consumer who encounters a sequence like this is entitled to report an error and not even try to render it.
  2. Allow it in the spec, and assign semantics to the size of the difference from one nesting level to the next.
  3. Allow it in the spec, but interpret any increase in nesting level the same as a single indent, and any decrease as a single outdent.

 

If we chose Option 3, then a viewer would be entitled to interpret [ 0, 0, 5, 5, 9, 9, 7, 7, 2, 2 ] as exactly equivalent to [ 0, 0, 1, 1, 2, 2, 1, 1, 0, 0 ].

 

Michael: At the moment, Chris and I have chosen Option 3 in implementing the V2 SARIF Viewer.

 

Whichever we choose, we need to document it.

 

Thoughts?

 

Larry



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