OASIS Static Analysis Results Interchange Format (SARIF) TC

The spec says:   The format of fullyQualifiedLogicalName SHALL be consistent with the programming language in which the programmatic construct specified by that logical location was expressed. EXAMPLE 1: C: create_process EXAMPLE 2: C++: Namespace1::Class::Method(int, double) const && EXAMPLE 3: C#: Namespace1.Class.Method(string, int[]) But we’ve talked about loosening that SHALL because you had some examples where it didn’t make sense. (I placed a comment in the change draft for #145 to remind me to take this up with you.)   What’s the scenario where FQLN doesn’t match a programming language construct? Did it have to do with tools that analyzed in-memory object models rather than source code?   Larry

To provide examples, there’s no syntactic method in most languages for referencing things like method parameters, return values, or local variables within the method. In _javascript_, there’s no syntactic method for referring anonymous methods is another. For these examples, tooling typically needs to contrive a convention when referring to them in analysis output, within a debugger or profiling tool, etc.   From: Larry Golding (Comcast) <larrygolding@comcast.net> Sent: Friday, May 4, 2018 10:56 AM To: Michael Fanning <Michael.Fanning@microsoft.com>; sarif@lists.oasis-open.org Subject: fullyQualifiedLogicalName syntax Importance: High   The spec says:   The format of fullyQualifiedLogicalName SHALL be consistent with the programming language in which the programmatic construct specified by that logical location was expressed. EXAMPLE 1: C: create_process EXAMPLE 2: C++: Namespace1::Class::Method(int, double) const && EXAMPLE 3: C#: Namespace1.Class.Method(string, int[]) But we’ve talked about loosening that SHALL because you had some examples where it didn’t make sense. (I placed a comment in the change draft for #145 to remind me to take this up with you.)   What’s the scenario where FQLN doesn’t match a programming language construct? Did it have to do with tools that analyzed in-memory object models rather than source code?   Larry

Right, thanks. I’ll file an issue.   From: Michael Fanning <Michael.Fanning@microsoft.com> Sent: Friday, May 4, 2018 11:31 AM To: Larry Golding (Comcast) <larrygolding@comcast.net>; sarif@lists.oasis-open.org Subject: RE: fullyQualifiedLogicalName syntax   To provide examples, there’s no syntactic method in most languages for referencing things like method parameters, return values, or local variables within the method. In _javascript_, there’s no syntactic method for referring anonymous methods is another. For these examples, tooling typically needs to contrive a convention when referring to them in analysis output, within a debugger or profiling tool, etc.   From: Larry Golding (Comcast) < larrygolding@comcast.net > Sent: Friday, May 4, 2018 10:56 AM To: Michael Fanning < Michael.Fanning@microsoft.com >; sarif@lists.oasis-open.org Subject: fullyQualifiedLogicalName syntax Importance: High   The spec says:   The format of fullyQualifiedLogicalName SHALL be consistent with the programming language in which the programmatic construct specified by that logical location was expressed. EXAMPLE 1: C: create_process EXAMPLE 2: C++: Namespace1::Class::Method(int, double) const && EXAMPLE 3: C#: Namespace1.Class.Method(string, int[]) But we’ve talked about loosening that SHALL because you had some examples where it didn’t make sense. (I placed a comment in the change draft for #145 to remind me to take this up with you.)   What’s the scenario where FQLN doesn’t match a programming language construct? Did it have to do with tools that analyzed in-memory object models rather than source code?   Larry