RE: codeFlowLocation.location not required

“at this point in time, an unknown external resource locks a file”

… sounds like a plausible use for this. You can probably think of others. Unless anyone objects, I’ll make that change in the spec.

Larry

From: Michael Fanning <Michael.Fanning@microsoft.com>
Sent: Monday, April 9, 2018 1:52 PM
To: Larry Golding (Comcast) <larrygolding@comcast.net>
Cc: sarif@lists.oasis-open.org
Subject: RE: codeFlowLocation.location not required

Well, the SDV team found it useful to capture the notion of a location-free ‘continuance’ kind. You can think of this record as a kind of location-free ‘edge’ between to interesting locations. You could imagine trying to produce an actual location for this part of the execution flow but the SDV team apparently didn’t find that helpful as far as building its viewer experience is concerned.

I’ve thought about this a bit and I wonder whether we shouldn’t loosen the restriction. If you think about concurrent analyses in particular, they might be developed against execution that has more to do with the synchronization/ordering of various things (like resource access) rather than a specific location. And so you can imagine a tool that might provide a speculative entry intended to represent, e.g., ‘at this point in time, an unknown external resource locks a file’. There would be no location for the code flow element to represent this. Obviously, other parts of the code flow (covering the code in question that needs to be proof against unexpected file locks) would have location details.

Michael

From: Larry Golding (Comcast) <larrygolding@comcast.net>
Sent: Saturday, April 7, 2018 10:38 AM
To: Michael Fanning <Michael.Fanning@microsoft.com>
Cc: sarif@lists.oasis-open.org
Subject: codeFlowLocation.location not required

When I made the location changes (#130), I wrote in the spec that codeFlowLocation.location is required. Seems sensible, right?

But when Chris made the SDK changes, he found that the SDV converter sometimes creates code flow locations with no location-related information. If we make codeFlowLocation.location required, these code flow locations end up with an emptylocation object:

Sarif.FunctionalTests/ConverterTestData/StaticDriverVerifier/checkadddevice_bug1.tt.sarif

{		{
	"step": 3,		"step": 3,
			+ "location": {},
	"kind": "continuation",		"kind": "continuation",
	"importance": "unimportant"		"importance": "unimportant"
	},

Is this a converter bug, or does it really make sense for a codeFlowLocation to have no location property?

Larry

sarif message