8000 Consistently use fully qualified type names in Java external flow method signatures · Issue #12290 · github/codeql · GitHub
[go: up one dir, main page]

Skip to content
Consistently use fully qualified type names in Java external flow method signatures #12290
Open
@knutwannheden

Description

@knutwannheden

The data flows described by the YAML files in https://github.com/github/codeql/tree/main/java/ql/lib/ext optionally contain method signatures, when the data only applies to specific overloads of the method by the given name. Typically these signatures have been specified using unqualified type references, as in the following examples:

- ["javax.json", "Json", False, "createArrayBuilder", "(Collection)", "", "Argument[0].Element", "ReturnValue", "taint", "manual"]
- ["javax.json", "Json", False, "createArrayBuilder", "(JsonArray)", "", "Argument[0]", "ReturnValue", "taint", "manual"]

There are however also many cases, where qualified type names are used. Here are a few examples of this kind:

- ["org.springframework.util", "StreamUtils", False, "copy", "(byte[],java.io.OutputStream)", "", "Argument[0]", "Argument[1]", "taint", "manual"]
- ["org.springframework.util", "StreamUtils", False, "copy", "(java.io.InputStream,java.io.OutputStream)", "", "Argument[0]", "Argument[1]", "taint", "manual"]
- ["org.springframework.util", "StreamUtils", False, "copy", "(java.lang.String,java.nio.charset.Charset,java.io.OutputStream)", "", "Argument[0]", "Argument[2]", "taint", "manual"]

For the generated data the type references appear to consistently be unqualified.

While I don't know how CodeQL currently consumes these models, I would have expected it to be an advantage to always have fully qualified type references, to be able to unambiguously resolve the type references and in the end the method. Theoretically it would for instance be possible that a given library adds a new overload, where a parameter has the same unqualified name as another overload and that the CodeQL model could then not be resolved unambiguously anymore.

While all these models could probably be processed in an automated manner to consistently use qualified type names, it would probably make sense to introduce checks to ensure that no future models start using unqualified type names again.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      0