#359: Constraints on state objects

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

sarif message