[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sarif] RE: Please comment on #125
This is right. And it really does illustrate what an odd corner case this is. You have to use a uriBaseId to construct a reference for this because the otherwise identical absolute URLs don’t comprise unique keys for the files table. Btw – this example sheds light on a need for some general guidance for how to handle embedded file contents. In this corner case, you must absolutely prefer the embedded content because it might not exist anywhere else (i.e., it was never
in source control or it was on disk previously but was subsequently overwritten).
But does it make sense as a rule to tell people to prefer the embedded file contents if it exists? I think it does as I think about it. In cases where you are certain to have access to files properly matched to your SARIF results (such
as if you just completed a local analysis or if your absolute URLs are versioned and point to accessible copies of the file), producers should not generate the embedded file contents. As a rule, injecting the file contents is a post-processing step that is
explicitly completed because the log file is being prepared for ingestion into a results mgmt. system (attached to a work item, persisted to a common remote store, etc.). Michael From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org>
On Behalf Of Larry Golding (Comcast) I see! A SARIF producer enables consumers to access previous versions of an overwritten file not just by
mentioning each version in the run.files dictionary, but by
persisting their contents there. It seems so obvious now
😊 I can write the text for this now. Editorial consideration: Explaining this, including an example, will take up a medium amount of space. And it’s not obvious where it does in the spec (in the
run.files section? In the
uriBaseId section?). So I propose to add a new non-normative Appendix to explain this corner case. Example below. Note the interplay between
originalUriBaseIds, result.location, and the property names in
run.files. It’s actually kind of elegant. It gives me faith in our format that it can represent this corner case in such a natural way. Larry { # A run object "originalUriBaseIds": { "generated-1": "file:///dev-machine/c:/project/out/obj", "generated-2": "file:///dev-machine/c:/project/out/obj" }, "results": [ { "ruleId": "CA4567", "location": { "physicalLocation": { "fileLocation": { "uri": "MainWindow.xaml.g.cs", "uriBaseId": "generated-1" }, "region": { "startLine": 42 } } } } ], "files": { "#generated-1#MainWindow.xaml.g.cs": { "fileContent": { # THIS IS WHAT MAKES IT WORK "text": "..." } }, "#generated-2#MainWindow.xaml.g.cs": { "fileContent": { "text": "..." } } } } From: Michael Fanning <Michael.Fanning@microsoft.com>
I’ve thought about this issue a bit. We should be thinking about an analysis that provides a hit in any generated file that isn’t under source control. For example, a generated XAML code-behind file. The corner case covers something even
more problematic, a single analysis run where generated files are, for example, overwritten on a per-project basis (to a common location in some build intermediates folder). To answer your questions:
From: Larry Golding (Comcast) <larrygolding@comcast.net>
#125:
Address corner case for generated files in run.files dictionary This is the scenario where the same physical file is re-written in the course of an analysis. Please see my comments in the issue. What is the scenario here? – that is:
Thanks, Larr |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]