Open davidmalcolm opened 10 months ago
Is this for statistics purposes? Counting how frequently asm sources have issues compared to other languages.
If this is instead for assigning already found issues to an employee who knows the language, then I expect you'd also need to indicate the processor family.
@KalleOlaviNiemitalo - Please check The spec, it explicit says:
If an artifact object represents a text artifact that contains source code, it MAY contain a property named sourceLanguage whose value is a hierarchical string (§3.5.4) that specifies the programming language in which the source code is written.
NOTE 1: This property is intended to help SARIF viewers to render code snippets with appropriate syntax coloring.
NOTE 2: Typically, this is the language implied by the file name extension.
Also there is an option to explicit declare a variant, the spec gives, in exact this place the sample "csharp/7", so once a language identifier is chosen, it can be "extended" with the assembly variant for example "assembler/gnu".
@davidmalcolm
The spec says for producers:
Do not abbreviate (for example, "visualbasic"™ rather than "vb")
So "assembler" should be preferred. For consumers it says
In addition, accept a variety of common industry forms, for example [...] {"javascript", "js"}.
so a consumer should also accept "asm".
I think that already answers this, no?
In any case, Appendix J is informative (not normative), it gives only examples.
As there is enough "space" left on that page, I still would suggest @sthagen (?) to ask for including "assembler" into appendix J.
Appendix J doesn't seem to have an entry for assembly language.
Would "asm" be a good one to add?