Paul, really appreciate you getting us this additional review, thanks so much. As unpleasant as it was to materialize at the last minute, it seems to me that the address design is greatly improved by this
last minute tinkering.
Thanks again. It s good to ship. Whew. Congratulations to all of us and thank you to everyone for all the hard work along the way. I m deeply grateful to all of you, and glad to have been a part of this experience.
Michael
From: Paul Anderson <
paul@grammatech.com>
Sent: Tuesday, April 30, 2019 6:42 PM
To: Larry Golding (Myriad Consulting Inc) <
v-lgold@microsoft.com>; James Kupsch <
kupsch@cs.wisc.edu>; Michael Fanning <
Michael.Fanning@microsoft.com>; OASIS SARIF TC Discussion List <
sarif@lists.oasis-open.org>
Subject: Re: [sarif] #401: Improved design of address object design
Awesome. Thanks!
On 4/30/2019 9:35 PM, Larry Golding (Myriad Consulting Inc) wrote:
Thank you Paul, I'm glad it meets your needs.
Jim spotted the missing word as well, and it's fixed in the version that will go out for ballot in the morning.
Best regards,
Larry
Get
Outlook for Android
From: Paul Anderson
Sent: Tuesday, April 30, 6:14 PM
Subject: Re: [sarif] #401: Improved design of address object design
To: Larry Golding (Myriad Consulting Inc), James Kupsch, Michael Fanning, OASIS SARIF TC Discussion List
Larry:
I'm on travel, but I asked Tom Johnson here to confirm that the recent
changes in this area will be good for our needs. He replied yes, but
spotted a typo. See the attached.
Best,
-Paul
On 4/29/2019 5:51 PM, Larry Golding (Myriad Consulting Inc) wrote:
> Got it
>
> -----Original Message-----
> From: James Kupsch
<
kupsch@cs.wisc.edu>
> Sent: Monday, April 29, 2019 2:50 PM
> To: Larry Golding (Myriad Consulting Inc)
<
v-lgold@microsoft.com> ; Michael Fanning
<
Michael.Fanning@microsoft.com> ; OASIS SARIF TC Discussion List
<
sarif@lists.oasis-open.org>
> Subject: Re: [sarif] #401: Improved design of address object design
>
> If length is negative, then it is downwards growing. If it is positive, then it is upwards growing. If it is null then it is unknown as it is just an address not a region.
>
> Jim
>
>
> On 4/29/19 4:46 PM, Larry Golding (Myriad Consulting Inc) wrote:
>> Oh good heavens, but that means that a negative offsetFromParent might not signal a downward-growing structure, so I can't write (as I already have) that "a negative value SHALL mean that
the data structure grows from higher addresses towards lower addresses".
>>
>> So what constraints _can_ I put on length/offsetFromParent/relative address, and what _is_ the reliable signal that I have a downward growing structure?
>>
>> Larry
>>
>> -----Original Message-----
>> From: James Kupsch
<
kupsch@cs.wisc.edu>
>> Sent: Monday, April 29, 2019 2:44 PM
>> To: Larry Golding (Myriad Consulting Inc)
<
v-lgold@microsoft.com> ;
>> Michael Fanning
<
Michael.Fanning@microsoft.com> ; OASIS SARIF TC
>> Discussion List
<
sarif@lists.oasis-open.org>
>> Subject: Re: [sarif] #401: Improved design of address object design
>>
>> They might not all have the same sign. Generally they should, but if you are trying to report a memory access that is outside of a container the sign might be the opposite, so probably a
SHOULD instead of a SHALL.
>>
>> Jim
>>
>>
>> On 4/29/19 4:36 PM, Larry Golding (Myriad Consulting Inc) wrote:
>>> Let's talk about length. I argued to Michael that it should just be a positive number of bytes.
>>>
>>> The only time you would need length to be negative is if you had a downward-growing structure, and your address object had _neither_ offsetFromParent _nor_ relativeAddress to signal the negative
value for you. Right?
>>>
>>> I'm willing to allow length to be negative for that situation (and therefore, Nullable to signal absence). It seems a pity that we have this Threefold Path for determining whether the data
structure is downward growing. And I suppose I have to say that of those that are present, all of them have to have the same sign!
>>>
>>> Now once again I wish for Boolean growsTowardLowAddresses, but ok, we agree that it's too error prone.
>>>
>>> So Michael are you ok with length/offsetFromParent/relativeAddress all being present, all allowed to be negative, and all required to have the same sign?
>>>
>>> Larry
>>>
>>> -----Original Message-----
>>> From: James Kupsch
<
kupsch@cs.wisc.edu>
>>> Sent: Monday, April 29, 2019 2:30 PM
>>> To: Larry Golding (Myriad Consulting Inc)
<
v-lgold@microsoft.com> ;
>>> Michael Fanning
<
Michael.Fanning@microsoft.com> ; OASIS SARIF TC
>>> Discussion List
<
sarif@lists.oasis-open.org>
>>> Subject: Re: [sarif] #401: Improved design of address object design
>>>
>>> supporting nullable would be useful. length and offsetFromParent would benefit from null. relativeToAddressAddressIndex would still be useful, but if you had null then it would not be required.
All the possible relativeAddresses and what they are relativeTo can be computed.
>>>
>>> On 4/29/19 4:23 PM, Larry Golding (Myriad Consulting Inc) wrote:
>>>> 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
<
kupsch@cs.wisc.edu>
>>>> *Sent:* Monday, April 29, 2019 2:19 PM
>>>> *To:* Larry Golding (Myriad Consulting Inc)
<
v-lgold@microsoft.com> ;
>>>> Michael Fanning
<
Michael.Fanning@microsoft.com> ; OASIS SARIF TC
>>>> Discussion List
<
sarif@lists.oasis-open.org>
>>>> *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 addressobject 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 addressobject *MAY* contain
>>>> a property named relativeAddresswhose value is an integer containing
>>>> the relative address (see 3.32.4) of thisObject.
>>>>
>>>> If parentIndexis absent, then relativeAddress*SHALL*be absent.
>>>>
>>>> If relativeAddressis 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,
>>>> relativeAddresscan 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 parentIndexis present, so we
>>>> can t use 0 as the default.
>>>>
>>>> Ideas?
>>>>
>>>> I m going to have lunch now. Back in a while.
>>>>
>>>> Larry
>>>>
>>>> *From:*
sarif@lists.oasis-open.org >>>> < mailto:
sarif@lists.oasis-open.org >
<
sarif@lists.oasis-open.org>
>>>> < mailto:
sarif@lists.oasis-open.org > *On Behalf Of *Larry Golding
>>>> (Myriad Consulting Inc)
>>>> *Sent:* Monday, April 29, 2019 12:59 PM
>>>> *To:* Michael Fanning
<
Michael.Fanning@microsoft.com>
>>>> < mailto:
Michael.Fanning@microsoft.com >; James Kupsch
>>>>
<
kupsch@cs.wisc.edu> < mailto:
kupsch@cs.wisc.edu >; OASIS SARIF TC
>>>> Discussion List
<
sarif@lists.oasis-open.org>
>>>> < mailto:
sarif@lists.oasis-open.org >
>>>> *Subject:* RE: [sarif] #401: Improved design of address object
>>>> design
>>>>
>>>> I approve this message! Much better than my solution.
>>>>
>>>> *From:*Michael Fanning <
Michael.Fanning@microsoft.com >>>> < mailto:
Michael.Fanning@microsoft.com >>
>>>> *Sent:* Monday, April 29, 2019 12:56 PM
>>>> *To:* James Kupsch <
kupsch@cs.wisc.edu < mailto:
kupsch@cs.wisc.edu >>;
>>>> Larry Golding (Myriad Consulting Inc) <
v-lgold@microsoft.com >>>> < mailto:
v-lgold@microsoft.com >>; OASIS SARIF TC Discussion List
>>>> <
sarif@lists.oasis-open.org < mailto:
sarif@lists.oasis-open.org >>
>>>> *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.