[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sarif] Change draft for #178 (column interpretation property)
Thanks Luke. Really, your original description of #178 explained this very well, and it’s my fault for misinterpreting it and making you explain it a second time. Sorry.
Yes, your enumerated columnKind property, along with the ancillary changes you suggest, seem like a good approach. I’ll put out another change draft.
In the issue, Michael wrote:
I agree with this and that also raises the question of whether column is the appropriate term to use in the format. It is clear that the information that is persisted to SARIF should be data that isn't subject to, for example, the configuration of the editor (I'd forgotten about the tabs -> columns issue).
This agrees with what you said below, except that Michael also specifies the default (and I agree with utf16CodeUnits as the default).
The other issue Michael raises is naming. I agree that “column” isn’t accurate. “character” is also wrong, both because of surrogate pairs and because of Unicode normalization issues with accented characters.
There is no English word for the concept we want, which is “the unit in which a language or tool measures string lengths”. We could coin “stringLengthUnit” or “stringUnit” but I don’t think it’s necessary.
IMO, we should continue to use column. As Michael said, many tools use this term in their output, even though it’s not strictly correct.
From: firstname.lastname@example.org <email@example.com> On Behalf Of Luke Cartey
I think this change draft doesn't quite solve the issue. In particular, I believe this restriction is wrong:
> for results reported in UTF-16-encoded files
It's not UTF-16 encoded files that are (specifically) the problem. The problem is that many languages internally represent strings as UTF-16 regardless of the original encoding of the file. For ease of implementation, static analysis tools written in these languages will often produce column numbers which count surrogate pairs as 2 columns, and all other code points as 1 column - i.e. count columns based on utf-16 code units, regardless of the original encoding.
Given that this can apply even when the file is not utf-16 encoded, I'm not sure specifying columns-per-surrogate pair is the right way to go.
My thought when I submitted the issue (which I didn't fully explain, sorry!) was that we should introduce an enumerated property called something like "columnKind", with options of:
This is more flexible than the column counting approach, as it allows us the option to add other column types later (utf8CodeUnit, for example).
I also note that this text still occurs in the change draft (3.22.2):
> In text files encoded in UTF-16, a “surrogate pair” [UNICODE10] SHALL be considered as a single character.
It looks like it should just be removed.
Also in the same section, we have:
> A column number represents a count of characters.
With the change, this is no longer true. This should be updated to reference the new property. I also think it should be made clear that the interpretation of the column count is not in any way reliant on the original encoding of the file.
Apologies for not sending this out sooner, I was away over the weekend.
On Sat, Jun 2, 2018 at 1:23 AM Larry Golding (Comcast) <firstname.lastname@example.org> wrote: