From: Larry Golding (Comcast) [mailto:larrygolding@comcast.net]
Sent: Monday, January 29, 2018 2:43 PM
To: 'Paul Anderson' <paul@grammatech.com>; mikefan@microsoft.com
Subject: RE: [sarif] Asking for output of analysis tools that produce code paths

Thanks Paul, that’s extremely helpful! I uploaded your samples to the directory Tool Samples/CodeSonar in the repo. I renamed the files to Leak.*, BufferOverrun.*, and DataRace.*. Here are my two main takeaways from studying them.

1. Event-to-event links

From the “buffer overrun” example, I see something I didn’t notice before: that your “events” (which seem to correspond to SARIF’s annotatedCodeLocations) can contain hyperlinks to other events.

Michael, this is different from what we implemented for Issue #66. Take a look at the samples to see what I mean. Their “event messages” can say things like this:

The resource was allocated at book.c:338.

… which is kind of like our new “embedded link to physical location” feature from Issue #66. But their event messages can also say things like this:

See related events 6, 7, and 12.

… which would be the equivalent of our being able to link from one step (annotatedCodeLocation) within a codeFlow to one or more other steps within the same codeFlow.

2. Multi-threading support

The “data race” example is particularly interesting because of the way your XML format segregates code locations among the different threads on which they execute:

...

</path>

...

</path>

</listing>

A SARIF codeFlow, in contrast, contains a simple array of annotatedCodeLocations. It’s true that annotatedCodeLocation has a property threadId, so a SARIF viewer could sort out which locations belong to which thread, and display them the way your HTML does. But your format makes the viewer’s job easier, and it makes it easier for a human reader to understand the raw XML file (for whatever that’s worth: Michael and I have tried to make SARIF a human-readable format, but the TC hasn’t (yet) adopted that as an explicit design goal. I’ll talk about that at the meeting).

Thanks again Paul. I look forward to exploring this further during our meeting. The agenda has time specifically set aside to discuss codeFlows.

Larry

From: Paul Anderson [mailto:paul@grammatech.com]
Sent: Monday, January 29, 2018 1:14 PM
To: Larry Golding (Comcast) <larrygolding@comcast.net>; mikefan@microsoft.com
Subject: Re: [sarif] Asking for output of analysis tools that produce code paths

Larry:

Sorry for not getting to this earlier!

I've attached a few files from CodeSonar. There's a leak, a buffer overrun, and a data race. The buffer overrun is the simplest as it is entirely intraprocedural. The leak has interprocedural flow. The data race has flow through two threads. The HTML is what the user sees. The XML is to facilitate integration. Both are generated from an internal form named ReML, one example of which is shown.

Enjoy!

-Paul

On 1/24/2018 4:59 PM, Larry Golding (Comcast) wrote:

One of our current discussion topics is whether the existing SARIF codeFlow object can represent the rich information produced by tools which trace execution paths through the code. It would help to have sample log files from such tools to review at our upcoming meeting.

If any of you have log files like that, could you please send them directly to Mike Fanning (mikefan@microsoft.com) and me, Larry Golding (larrygolding@comcast.net)?

Michael thought that some of you are likely to be able to supply logs like that:

Yekaterina O’Neil – Fortify
Paul Anderson – CodeSonar?
Mel Llaguno – Synopsis
Luke Cartey – Semmle
Mike Fanning – Static Driver Verifier (SDV)
Jim Kupsch – SWAMP-compatible tools?
Henny Sipma – Kestrel

… but the request is to any and all of you who can help.

Thanks,
Larry

--

Paul Anderson, VP of Engineering, GrammaTech, Inc.

531 Esty St., Ithaca, NY 14850

Tel: +1 607 273-7340 x118; http://www.grammatech.com

sarif message

1. Event-to-event links

2. Multi-threading support