I m going to go with the Nullables then, as it is consistent with Jim s original proposal. He didn t add relativeToAddressIndex because he liked it; he did it to try to help out our poor SDK.
I was almost done with the draft; I was just waiting for this to resolve. I ll push the draft in about half an hour and we should be good to go.
Larry
From:
Michael Fanning <>
Sent: Monday, April 29, 2019 2:26 PM
To: Larry Golding (Myriad Consulting Inc) <>; James Kupsch <>; OASIS SARIF TC Discussion List <>
Subject: RE: [sarif] #401: Improved design of address object design
Yes, I think we should be ready to just embrace a schema that requires a nullable type in C#. The specific proposal, when offsetFromParent or relativeAddress are _ absent _, they are truly absent and
cannot be consumed. When populated, whether negative, 0 or positive value, those values are honored.
This is very clear, doesn t require a new property, and comes at the small expense of requiring nullable types in the C# SDK.
Michael
From:
Larry Golding (Myriad Consulting Inc) <
>
Sent: Monday, April 29, 2019 2:24 PM
To: James Kupsch < >; Michael Fanning < >; OASIS SARIF TC Discussion List <
>
Subject: RE: [sarif] #401: Improved design of address object design
I appreciate you coming up with a nice idea that avoids Nullables, at the expense of one more property.
When Michael and I talked about it just now, we finally conceded that we have been tying ourselves in knots trying to avoid Nullables where they would naturally occur, and the best thing to do was just let
them into the SDK.
Would you agree that in the presence of Nullables, they are preferable to adding the new property?
Larry
From:
James Kupsch <
>
Sent: Monday, April 29, 2019 2:19 PM
To: Larry Golding (Myriad Consulting Inc) < >; Michael Fanning < >; OASIS SARIF TC Discussion List <
>
Subject: Re: [sarif] #401: Improved design of address object design
If you add a relativeToAddressIndex, then instead of making it relative to the top-most parent, you can make it relative to this object, and -1 works here as it can indicate unknown. This also allows two addresses (only if
the relativeToAddressIndex are identical and not -1) to be compared, and allows relativeness to other containers than the top most which might be more relevant. Below is an example. Empty values are unknown.
name: STACK1
kind: stack
length: -300000
offsetFromParent:
parentIndex:
relativeAddress:
relativeToAddressIndex:
absoluteAddress: 1250000
name: STACK1.frame4
kind: stackFrame
length: -2000
offsetFromParent: -1000
parentIndex: 0
relativeAddress: -1000
relativeToAddressIndex: 0
absoluteAddress: 1249000
name: variable444
kind: intData
length: 8
offsetFromParent: 32
parentIndex: 1
relativeAddress: -968
relativeToAddressIndex: 0
absoluteAddress: 1249030
On 4/29/19 3:20 PM, Larry Golding (Myriad Consulting Inc) wrote:
There s a problem with
relativeAddress , though. Here s what I currently have:
3.32.4 Relative address calculation
Each
address
object has an associated value called its relative address which is
the offset of the address from the address of the top-most object in its parent chain
3.32.7 relativeAddress property
If
parentIndex
( 3.32.13) is present, an
address
object
MAY contain a property named
relativeAddress
whose value is an integer containing
the relative address (see 3.32.4) of
thisObject .
If
parentIndex
is absent, then
relativeAddress
SHALL
be absent.
If
relativeAddress
is absent, it
SHALL default to -1, which is otherwise not a valid value for this property .
That s wrong. If your top-most address is a downward-growing stack,
relativeAddress
can be negative. And unlike
offsetFromParent , we can t say (I mean, we
can , but don t think we should) that
relativeAddress
SHALL be present if
parentIndex
is present, so we can t use 0 as the default.
Ideas?
I m going to have lunch now. Back in a while.
Larry
From:
<>
On Behalf Of Larry Golding (Myriad Consulting Inc)
Sent: Monday, April 29, 2019 12:59 PM
To: Michael Fanning <> ; James Kupsch
<> ; OASIS SARIF TC Discussion List
<>
Subject: RE: [sarif] #401: Improved design of address object design
I approve this message! Much better than my solution.
From:
Michael Fanning <
>
Sent: Monday, April 29, 2019 12:56 PM
To: James Kupsch < >; Larry Golding (Myriad Consulting Inc) < >; OASIS SARIF TC Discussion List <
>
Subject: RE: [sarif] #401: Improved design of address object design
Here s my suggestion:
For address.length, use a sentinel value of 0 meaning not provided . This makes sense, as Jim noted, a 0 length memory address isn t sensible. You don t posit describing an insertion point in memory that
shoves everything to the right.
