OASIS Static Analysis Results Interchange Format (SARIF) TC

  • 1.  "generatedFile" => "uncontrolledFile"

    Posted 05-17-2018 18:32
    For purposes of file.roles , generated files are interesting because they’re not under source control. There might be other files that are not under source control. Shall we rename "generatedFile" to "uncontrolledFile" ? (Other name suggestions welcome.)   Larry


  • 2.  Re: [sarif] "generatedFile" => "uncontrolledFile"

    Posted 05-17-2018 20:05
    It may be useful to have both of these. generatedFile implies uncontrolledFile, but there are other referenced files that are uncontrolled, but not generated, such as files that are part of the standard library of the language. If generatedFile is not useful, then uncontrolledFile is probably a better name. Jim On 05/17/2018 01:29 PM, Larry Golding (Comcast) wrote: For purposes of file.roles, generated files are interesting because they’re not under source control. There might be other files that are not under source control. Shall we rename "generatedFile" to "uncontrolledFile"? (Other name suggestions welcome.) Larry


  • 3.  RE: [sarif] "generatedFile" => "uncontrolledFile"

    Posted 05-17-2018 22:17
    We are at the part of the design discussion where we're trying to fill things out. We should be sure to do what you describe, understand the utility of each new role that we add. I understand why 'renamed file' is helpful. This allows for results matching across SARIF logs (where a file has one name in the first and another in the second). Now we should ask ourselves, how would a SARIF consumer usefully consume 'generatedFile' or 'uncontrolledFile'. One obvious answer is that a generated or uncontrolled file is specific to a local environment only. If you have a reference to one, it better be embedded in the log file or you'd better be evaluating the URI that points to it in the same environment where the log file was produced (and hope it hasn't been overwritten, if generated). The interest thinking exercise is, how useful is this? I'm going to spend some time thinking about possibilities, a couple of ideas occur to me, but still puzzling... Michael
    Original Message


  • 4.  RE: [sarif] "generatedFile" => "uncontrolledFile"

    Posted 05-18-2018 17:18
    The purpose of these roles is to help a SARIF consumer who can’t access a VCS to decide what files have changed (and so might need to be reanalyzed). Given that, I don’t see a useful distinction between a generated file and any other file that’s not under source control. In either case, the consumer either has to assume that the file has changed, or it has to keep track of a last-modified time, or a hash, of the file.   So I think generatedFile is not necessary as a separate property, and I propose we rename it to uncontrolledFile .  
    Original Message


  • 5.  RE: [sarif] "generatedFile" => "uncontrolledFile"

    Posted 05-18-2018 17:29
    * sigh * Actually there is a possible use. It’s often not possible to fix bugs in generated files, because you don’t have control of the generator. So a team might well decide to ignore all issues in generated files, so that role might be useful.   Of course in that case the team should just exclude the generated files from analysis. After all, if they know enough to mark the files as “generated” in the files dictionary, then they know exactly which files were generated.   So I’m still on the fence (but still leaning towards a simple rename).   Any thoughts from anyone else?   Larry   From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org> On Behalf Of Larry Golding (Comcast) Sent: Friday, May 18, 2018 10:16 AM To: 'James A. Kupsch' <kupsch@cs.wisc.edu>; sarif@lists.oasis-open.org Subject: RE: [sarif] "generatedFile" => "uncontrolledFile"   The purpose of these roles is to help a SARIF consumer who can’t access a VCS to decide what files have changed (and so might need to be reanalyzed). Given that, I don’t see a useful distinction between a generated file and any other file that’s not under source control. In either case, the consumer either has to assume that the file has changed, or it has to keep track of a last-modified time, or a hash, of the file.   So I think generatedFile is not necessary as a separate property, and I propose we rename it to uncontrolledFile .  
    Original Message


  • 6.  RE: [sarif] "generatedFile" => "uncontrolledFile"

    Posted 05-18-2018 17:54
    Also, Jim pointed out that issues might be found in standard library files. So, there are really three classes of files:   Files under source control. The existing roles unmodifiedFile , modifiedFile , addedFile , and deletedFile apply to them. Files not under source control, but under the control of the engineering team. Files not under source control, and not under the control of the engineering team. This includes standard library files, and generated files for which the engineering team does not control the generator.   One possibility is:   Remove generatedFile . Add uncontrolledFile to cover category #2. Add excludedFile to cover category #3 (and any other file that the team wants to exclude from analysis “after the fact”)   Larry   From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org> On Behalf Of Larry Golding (Comcast) Sent: Friday, May 18, 2018 10:27 AM To: 'James A. Kupsch' <kupsch@cs.wisc.edu>; sarif@lists.oasis-open.org Subject: RE: [sarif] "generatedFile" => "uncontrolledFile"   * sigh * Actually there is a possible use. It’s often not possible to fix bugs in generated files, because you don’t have control of the generator. So a team might well decide to ignore all issues in generated files, so that role might be useful.   Of course in that case the team should just exclude the generated files from analysis. After all, if they know enough to mark the files as “generated” in the files dictionary, then they know exactly which files were generated.   So I’m still on the fence (but still leaning towards a simple rename).   Any thoughts from anyone else?   Larry   From: sarif@lists.oasis-open.org < sarif@lists.oasis-open.org > On Behalf Of Larry Golding (Comcast) Sent: Friday, May 18, 2018 10:16 AM To: 'James A. Kupsch' < kupsch@cs.wisc.edu >; sarif@lists.oasis-open.org Subject: RE: [sarif] "generatedFile" => "uncontrolledFile"   The purpose of these roles is to help a SARIF consumer who can’t access a VCS to decide what files have changed (and so might need to be reanalyzed). Given that, I don’t see a useful distinction between a generated file and any other file that’s not under source control. In either case, the consumer either has to assume that the file has changed, or it has to keep track of a last-modified time, or a hash, of the file.   So I think generatedFile is not necessary as a separate property, and I propose we rename it to uncontrolledFile .  
    Original Message


  • 7.  RE: [sarif] "generatedFile" => "uncontrolledFile"

    Posted 05-21-2018 19:47
    In a phone call, Michael pointed out that there are many reasons a file might be excluded from analysis:   It was generated by the build. It’s part of a standard library It’s test code ...   So potential roles like “excluded file” and “generated file” are related to the “result management” domain. They don’t fit into the set of roles we approved at the last meeting, which were all related to version control.   You could certainly imagine adding a set of result-management-related roles in future.   For now, we propose to change this:   "generatedFile" : The file was generated by the build.   … to this:   "uncontrolledFile" : The file is not under version control.   I reopened Issue #143 , “Roles for edited files”, to capture this proposal, and placed it on the agenda for TC #18 on May 30 th .   Larry   From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org> On Behalf Of Larry Golding (Comcast) Sent: Friday, May 18, 2018 10:52 AM To: 'James A. Kupsch' <kupsch@cs.wisc.edu>; sarif@lists.oasis-open.org Subject: RE: [sarif] "generatedFile" => "uncontrolledFile"   Also, Jim pointed out that issues might be found in standard library files. So, there are really three classes of files:   Files under source control. The existing roles unmodifiedFile , modifiedFile , addedFile , and deletedFile apply to them. Files not under source control, but under the control of the engineering team. Files not under source control, and not under the control of the engineering team. This includes standard library files, and generated files for which the engineering team does not control the generator.   One possibility is:   Remove generatedFile . Add uncontrolledFile to cover category #2. Add excludedFile to cover category #3 (and any other file that the team wants to exclude from analysis “after the fact”)   Larry   From: sarif@lists.oasis-open.org < sarif@lists.oasis-open.org > On Behalf Of Larry Golding (Comcast) Sent: Friday, May 18, 2018 10:27 AM To: 'James A. Kupsch' < kupsch@cs.wisc.edu >; sarif@lists.oasis-open.org Subject: RE: [sarif] "generatedFile" => "uncontrolledFile"   * sigh * Actually there is a possible use. It’s often not possible to fix bugs in generated files, because you don’t have control of the generator. So a team might well decide to ignore all issues in generated files, so that role might be useful.   Of course in that case the team should just exclude the generated files from analysis. After all, if they know enough to mark the files as “generated” in the files dictionary, then they know exactly which files were generated.   So I’m still on the fence (but still leaning towards a simple rename).   Any thoughts from anyone else?   Larry   From: sarif@lists.oasis-open.org < sarif@lists.oasis-open.org > On Behalf Of Larry Golding (Comcast) Sent: Friday, May 18, 2018 10:16 AM To: 'James A. Kupsch' < kupsch@cs.wisc.edu >; sarif@lists.oasis-open.org Subject: RE: [sarif] "generatedFile" => "uncontrolledFile"   The purpose of these roles is to help a SARIF consumer who can’t access a VCS to decide what files have changed (and so might need to be reanalyzed). Given that, I don’t see a useful distinction between a generated file and any other file that’s not under source control. In either case, the consumer either has to assume that the file has changed, or it has to keep track of a last-modified time, or a hash, of the file.   So I think generatedFile is not necessary as a separate property, and I propose we rename it to uncontrolledFile .  
    Original Message


Related Content