RE: fullyQualifiedLogicalName syntax

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

sarif message