sarif — archive

[Laurence Golding]

In a comment on Issue #168 , Jim made this suggestion: For many of the tools that I have seen that include flows or traversals, when explaining a flow or graph traversal state, they specify the value of an _expression_ as a literal value (expressible in this current design), or as a constraint on the value (currently not not expressible). Such as {   "i":  "i < 5",   "j":  "j >= 10 && j < 100",   "p":  "p != NULL ",   "r":  "r == NULL",   "s":  "strlen(s) > 100",   "t":  "buffer t is not NULL terminated" } This state constraint information that many tools report, could incorporate this without changing the schema by describing that a magic string value such as "{expr}" is used to represent a constraint _expression_. If "{expr}" exists in the value then it is a constraint (the value may substitute the actual _expression_ for {expr}. If "{expr}" does not exist in the value then this is an equality constraint equivalent to "{expr} == VALUE" where VALUE is the value of the JSON property. The above constraints would then become a state object of {   "i":  "{expr} < 5",   "j":  "{expr} >= 10 && {expr} < 100",   "p":  "{expr} != NULL ",   "r":  "NULL",   "s":  "strlen({expr}) > 100",   "t":  "buffer {expr} is not NULL terminated" } For viewer just displaying the values above would probably be deciphered with the correct meaning by most developers, and advanced viewers could do more to indicate a general constraint instead of just equality. This is a nice design enhancement and it’s a non-breaking change with only one little bit of magic to explain, and I have the time, so I will incorporate it. I filed Issue #359 , “Constraints in state objects.” If anyone objects, please let us know. Larry