Awesome. Thanks!
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
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-----
> Sent: Monday, April 29, 2019 2:50 PM
> 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-----
>> Sent: Monday, April 29, 2019 2:44 PM
>> 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-----
>>> Sent: Monday, April 29, 2019 2:30 PM
>>> 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
>>>>
>>>> *Sent:* Monday, April 29, 2019 2:19 PM
>>>> *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
>>>>ÂÂÂÂÂÂÂ (Myriad Consulting Inc)
>>>>ÂÂÂÂÂÂÂ *Sent:* Monday, April 29, 2019 12:59 PM
>>>>ÂÂÂÂÂÂÂ *Subject:* RE: [sarif] #401: Improved
design of address object
>>>> design
>>>>
>>>>ÂÂÂÂÂÂÂ I approve this message! Much better than
my solution.
>>>>
>>>>ÂÂÂÂÂÂÂ *Sent:* Monday, April 29, 2019 12:56 PM
>>>>ÂÂÂÂÂÂÂ *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. ð
>>>>
>>>>ÂÂÂÂÂÂÂ For address.offsetFromParent, this
property should only be consulted
>>>>ÂÂÂÂÂÂÂ in cases where address.parentIndex >=
0. If address.parentIndex is
>>>>ÂÂÂÂÂÂÂ -1, you ignore the offsetFromParent
value (in all cases). If
>>>>ÂÂÂÂÂÂÂ address.parentIndex >= 0, the
address.offsetFromParent must be
>>>>ÂÂÂÂÂÂÂ populated (and it is fine if its value
is 0).
>>>>
>>>>ÂÂÂÂÂÂÂ This requires producers to always
provided offsetFromParent when
>>>>ÂÂÂÂÂÂÂ using the address parenting chain. IOW,
you canât describe your
>>>>ÂÂÂÂÂÂÂ parenting relationship and depend
strictly on relativeAddress and/or
>>>>ÂÂÂÂÂÂÂ absoluteAddress to render those final
computed values. I think this
>>>>ÂÂÂÂÂÂÂ trade-off is ok, particularly as
compared to consulting a separate
>>>>ÂÂÂÂÂÂÂ Boolean in order to know whether youâre
going backward in memory.
>>>>
>>>>ÂÂÂÂÂÂÂ Michael
>>>>
>>>>ÂÂÂÂÂÂÂ *Sent:* Monday, April 29, 2019 12:46 PM
>>>>ÂÂÂÂÂÂÂ *Subject:* Re: [sarif] #401: Improved
design of address object
>>>> design
>>>>
>>>>ÂÂÂÂÂÂÂ The unknown is only for this address to
its parents. The same
>>>>ÂÂÂÂÂÂÂ problem exists whether you use -1 or
unknownOffset/Length. It is
>>>>ÂÂÂÂÂÂÂ useful to know offsets up to the point
of where it is unknown as you
>>>>ÂÂÂÂÂÂÂ at least know it is relative to this
address (grand..)parent
>>>> object. The cleaner approach to working
around the SDK not
>>>>ÂÂÂÂÂÂÂ supporting nullable is to use the extra
boolean.
>>>>
>>>>ÂÂÂÂÂÂÂ On 4/29/19 2:18 PM, Larry Golding
(Myriad Consulting Inc) wrote:
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂ I really think my previous
suggestion of growthDirection is the
>>>>ÂÂÂÂÂÂÂÂÂÂÂ least bad alternative if we decide
*/NOT/* to use Nullable<int>.
>>>>ÂÂÂÂÂÂÂÂÂÂÂ Iâd modify my proposal to a Boolean
growsTowardLowMemory,
>>>>ÂÂÂÂÂÂÂÂÂÂÂ default false.
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂ (Myriad Consulting Inc)
>>>>ÂÂÂÂÂÂÂÂÂÂÂ *Sent:* Monday, April 29, 2019 11:46
AM
>>>>ÂÂÂÂÂÂÂÂÂÂÂ *Subject:* RE: [sarif] #401:
Improved design of address object
>>>>ÂÂÂÂÂÂÂÂÂÂÂ design
>>>>ÂÂÂÂÂÂÂÂÂÂÂ *Importance:* High
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂ Iâm not as happy as I was a few
moments ago. If the âunknownâ
>>>>ÂÂÂÂÂÂÂÂÂÂÂ properties default to false, then if
you donât populate
>>>>ÂÂÂÂÂÂÂÂÂÂÂ offsetFromParent (which happens at
the top of every parent
>>>>ÂÂÂÂÂÂÂÂÂÂÂ chain) or length (which can happen
anywhere along the parent
>>>>ÂÂÂÂÂÂÂÂÂÂÂ chain), then you have to remember to
set the corresponding
>>>>ÂÂÂÂÂÂÂÂÂÂÂ âunknownâ property. You wonât. Of if
the âunknownâ properties
>>>>ÂÂÂÂÂÂÂÂÂÂÂ default to true, you have to set
them to false whenever you /do/
>>>>ÂÂÂÂÂÂÂÂÂÂÂ populate offsetFromParent or length.
You wonât.
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂ *Michael* (addressing this question
specifically to him because
>>>>ÂÂÂÂÂÂÂÂÂÂÂ of the SDK impact), I donât see a
good alternative to
>>>>ÂÂÂÂÂÂÂÂÂÂÂ Nullable<int>. Please let us
know your opinion. Raising to red-bang.
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂ Larry
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂ *From:* Larry Golding (Myriad
Consulting Inc)
>>>>ÂÂÂÂÂÂÂÂÂÂÂ *Sent:* Monday, April 29, 2019 11:37
AM
>>>>ÂÂÂÂÂÂÂÂÂÂÂ *Subject:* RE: [sarif] #401:
Improved design of address object
>>>>ÂÂÂÂÂÂÂÂÂÂÂ design
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂ I could accept Boolean unknownLength
and
>>>>ÂÂÂÂÂÂÂÂÂÂÂ unknownOffsetFromParent, default
false for both.
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂ I will write it this way and send a
draft. I can always change
>>>>ÂÂÂÂÂÂÂÂÂÂÂ this aspect of the design if the TC
objects.
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂ Larry
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂ -----Original Message-----
>>>>ÂÂÂÂÂÂÂÂÂÂÂ Sent: Monday, April 29, 2019 11:30
AM
>>>>ÂÂÂÂÂÂÂÂÂÂÂ Subject: Re: [sarif] #401: Improved
design of address
>>>> object design
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂ I think this alternative complicates
the math for consumers, a
>>>>ÂÂÂÂÂÂÂÂÂÂÂ boolean name unknownLength and
unknownOffset would be better
>>>>ÂÂÂÂÂÂÂÂÂÂÂ choices if there can't be a null
value. The default value could
>>>>ÂÂÂÂÂÂÂÂÂÂÂ be the length not equal to the
default length or offset (-1
>>>> would be good default). Then length
and offset can take any
>>>>ÂÂÂÂÂÂÂÂÂÂÂ value, negative or positive.
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂ Jim
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂ On 4/29/19 12:45 PM, Larry Golding
(Myriad Consulting Inc) wrote:
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > As an alternative to allowing
lengthand offsetFromParentto be
>>>>ÂÂÂÂÂÂÂÂÂÂÂ negative,
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > we could define a property
growthDirection(or even just
>>>>ÂÂÂÂÂÂÂÂÂÂÂ direction)
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > values "positive"and
"negative", default value "positive". If
>>>>ÂÂÂÂÂÂÂÂÂÂÂ itâs
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > "negative", then both
offsetFromParentand lengthare
>>>>ÂÂÂÂÂÂÂÂÂÂÂ interpreted as
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > negative numbers.
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > Iâm not 100% happy with that
either â it would be too easy
>>>>ÂÂÂÂÂÂÂÂÂÂÂ for an SDK
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > consumer to add
offsetFromParentto its parent address without
>>>>ÂÂÂÂÂÂÂÂÂÂÂ noticing
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > it should have reversed the
sign.
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > *From:*Larry Golding (Myriad
Consulting Inc)
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > *Sent:* Monday, April 29, 2019
10:25 AM
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > *To:* Larry Golding (Myriad
Consulting Inc)
>>>>
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂ Discussion List
>>>>
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > *Subject:* RE: [sarif] #401:
Improved design of address
>>>>ÂÂÂÂÂÂÂÂÂÂÂ object design
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > Another question: What does a
lengthof zero mean? Is it an
>>>>ÂÂÂÂÂÂÂÂÂÂÂ âinsertion
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > pointâ, a zero-length range
preceding the location
>>>> specified by
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
offsetFromParent/absoluteAddress/relativeAddress?
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
*From:*sarif@lists.oasis-open.org
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂ *On
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > Behalf Of *Larry Golding
(Myriad Consulting Inc)
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > *Sent:* Monday, April 29, 2019
10:18 AM
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂ
>>>>
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂ Discussion List
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂ
>>>> org>>>
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > *Subject:* RE: [sarif] #401:
Improved design of address
>>>>ÂÂÂÂÂÂÂÂÂÂÂ object design
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > Sorry, I shouldnât have
directed those questions only to
>>>>ÂÂÂÂÂÂÂÂÂÂÂ Michael. It was
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > just because he proposed the
original redesign in #403. Of
>>>>ÂÂÂÂÂÂÂÂÂÂÂ course I want
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > to hear feedback from the
entire TC.
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > *From:*Larry Golding (Myriad
Consulting Inc)
>>>>
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > *Sent:* Monday, April 29, 2019
10:16 AM
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > *To:* Larry Golding (Myriad
Consulting Inc)
>>>>
>>>>
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂ
>>>> c
>>>> r
>>>> osoft.com>>>;
>>>>
>>>>
>>>>
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > *Subject:* RE: [sarif] #401:
Improved design of address
>>>>ÂÂÂÂÂÂÂÂÂÂÂ object design
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > Another concern I have is
around length. I want to be able to
>>>>ÂÂÂÂÂÂÂÂÂÂÂ write that
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > if an addressobject occurs
within a physicalLocationobject
>>>>ÂÂÂÂÂÂÂÂÂÂÂ thisObject,
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > and if thisObject.lengthand
thisObject.address.lengthare both
>>>>ÂÂÂÂÂÂÂÂÂÂÂ present,
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > then then *SHALL* be equal.
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > As the spec stands, I canât
write this because
>>>>ÂÂÂÂÂÂÂÂÂÂÂ physicalLocation.lengthis
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > non-negative. I can add words
like this:
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > If an addressobject occurs
within a physicalLocationobject
>>>>ÂÂÂÂÂÂÂÂÂÂÂ thisObject,
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > and if thisObject.lengthand
thisObject.address.lengthare both
>>>>ÂÂÂÂÂÂÂÂÂÂÂ present,
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > then then *SHALL* be equal. In
that case, if
>>>>ÂÂÂÂÂÂÂÂÂÂÂ thisObject.address.lengthis
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > negative, then
thisObject.lengthwill also be negative. In all
>>>>ÂÂÂÂÂÂÂÂÂÂÂ other
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > circumstances, lengthSHALL be
non-negative.
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > *Michael*, are you ok with
that complication?
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > Larry
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
*From:*sarif@lists.oasis-open.org
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂ *On
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > Behalf Of *Larry Golding
(Myriad Consulting Inc)
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > *Sent:* Monday, April 29, 2019
10:08 AM
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂ
>>>>
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂ Discussion List
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂ
>>>> org>>>
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > *Subject:* RE: [sarif] #401:
Improved design of address
>>>>ÂÂÂÂÂÂÂÂÂÂÂ object design
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > Jim,
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >Â From an SDK standpoint we
have a problem with negative
>>>>ÂÂÂÂÂÂÂÂÂÂÂ values because
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > without -1 as a sentinel
value, we need to make the
>>>> .NET type
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > Nullable<int>instead of
int. So far we have avoided nullables
>>>>ÂÂÂÂÂÂÂÂÂÂÂ in the
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > API. Our code generation
doesnât currently support them, but
>>>>ÂÂÂÂÂÂÂÂÂÂÂ it wouldnât
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > be hard to add.
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > *Michael*, could you weigh in
on this? The .NET
>>>> Framework Design
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > Guidelines (Â8.8) say:
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > *CONSIDER*using
Nullable<T>to represent values that might not
>>>>ÂÂÂÂÂÂÂÂÂÂÂ be present
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > (/i.e./, optional values).
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > **
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > â and a quick web search
doesnât turn up recommendations to
>>>>ÂÂÂÂÂÂÂÂÂÂÂ avoid them
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > in this scenario.
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > Iâd just be concerned that
this is the only place we have
>>>>ÂÂÂÂÂÂÂÂÂÂÂ nullables. Are
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > there alternatives?
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > In the meantime Iâll write the
words for the rest of Jimâs
>>>>ÂÂÂÂÂÂÂÂÂÂÂ feedback.
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > Larry
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂ
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > *Sent:* Monday, April 29, 2019
8:40 AM
>>>>
>>>>
>>>> (Myriad
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂ
>>>>
>>>>
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > *Subject:* Re: [sarif] #401:
Improved design of address
>>>>ÂÂÂÂÂÂÂÂÂÂÂ object design
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > For #2,IÂ was thinking the
"stack" kind would be the whole
>>>> stack. Also
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > having a "stackFrame" kind
would also be useful as it also a
>>>>ÂÂÂÂÂÂÂÂÂÂÂ defined
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > memory region contained within
the "stack" kind.
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > JIm
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > On 4/29/19 10:20 AM, Michael
Fanning wrote:
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > Right now, the effective
address is absolute if unparented
>>>>ÂÂÂÂÂÂÂÂÂÂÂ and relative
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > to some other thing, if
parented.
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > If you chase to the root
object, letâs say itâs a module, its
>>>>ÂÂÂÂÂÂÂÂÂÂÂ effective
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > address provides the ability
to distinguish a childâs
>>>>ÂÂÂÂÂÂÂÂÂÂÂ relative address
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > vs. physical memory location.
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > IOW, the childâs relative
address is its offset + all offsets
>>>>ÂÂÂÂÂÂÂÂÂÂÂ up to (but
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > not including) the root
object. If you add the effective
>>>>ÂÂÂÂÂÂÂÂÂÂÂ address of the
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > root object, you get the
absolute memory address (if available).
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > Make sense? What do you think?
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > For #2 stack, is the kind a
stack frame?
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > For #3, I see the problem.
Every address in a PLC has an
>>>>ÂÂÂÂÂÂÂÂÂÂÂ associated
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > region but the run.addresses
cache does not provide this
>>>>ÂÂÂÂÂÂÂÂÂÂÂ association.
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > Let me have a word with Larry.
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
*From:*sarif@lists.oasis-open.org
>>>>
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > Behalf Of *James Kupsch
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > *Sent:* Monday, April 29, 2019
8:06 AM
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > *To:* Larry Golding (Myriad
Consulting Inc)
>>>>
>>>> Discussion List
>>>>
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > *Subject:* Re: [sarif] #401:
Improved design of address
>>>>ÂÂÂÂÂÂÂÂÂÂÂ object design
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > After reading the address
section changes. I have a couple
>>>>ÂÂÂÂÂÂÂÂÂÂÂ of comments:
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > 1) I would think that a common
use of address would be
>>>>ÂÂÂÂÂÂÂÂÂÂÂ something on the
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > stack. To facilitate this, the
offsetFromParent should be
>>>>ÂÂÂÂÂÂÂÂÂÂÂ allowed to be
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > negative as the "bottom" of
stack is most logical place to be
>>>>ÂÂÂÂÂÂÂÂÂÂÂ offset
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > from, and since some stacks
grow from higher to lower memory
>>>>ÂÂÂÂÂÂÂÂÂÂÂ addresses,
>>>>
>>>> > the offset is negative. The
use of -1 for unknown mechanism
>>>>ÂÂÂÂÂÂÂÂÂÂÂ would have
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > to be changed for this to
work.
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > 2) Add stack as a kind
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > 3) There is a length in
physical location, but not all
>>>>ÂÂÂÂÂÂÂÂÂÂÂ addresses will
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > appear in a physical location
(probably just those without
>>>>ÂÂÂÂÂÂÂÂÂÂÂ parentIndex)
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > a length field would be
useful. This allows the producers to
>>>>ÂÂÂÂÂÂÂÂÂÂÂ specify
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > the lengths of the parent
addresses that are regions in
>>>>ÂÂÂÂÂÂÂÂÂÂÂ memory, and for
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > consumers to determine them.
The length should be allowed to
>>>>ÂÂÂÂÂÂÂÂÂÂÂ be negative
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > to handle the stack case
cleanly and to indicate that it
>>>>ÂÂÂÂÂÂÂÂÂÂÂ grows towards
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > decreasing values (if length
is negative the regions is from
>>>>ÂÂÂÂÂÂÂÂÂÂÂ (address -
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > offset) to address. For
instance if I have an address in a
>>>>ÂÂÂÂÂÂÂÂÂÂÂ physical
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > object, a question that I
might want to know is does this
>>>>ÂÂÂÂÂÂÂÂÂÂÂ address
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > overflow a containing memory
region.
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > 4) effectiveAddress can be one
of two types of addresses: a
>>>>ÂÂÂÂÂÂÂÂÂÂÂ relative
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > address to some logical
memory/file region, and an absolute
>>>>ÂÂÂÂÂÂÂÂÂÂÂ memory
>>>>
>>>> > address. These concepts are
independent, are both useful,
>>>>ÂÂÂÂÂÂÂÂÂÂÂ and should be
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > distinguishable from one
another. Something like:
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > *offsetFromParent* - offset
from containing parent (same as
>>>>ÂÂÂÂÂÂÂÂÂÂÂ existing)
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > *parentIndex*Â - direct
container address region if there is
>>>>ÂÂÂÂÂÂÂÂÂÂÂ one (same
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > as existing)
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
*offsetFromLogicalAddressRegion*Â - offset from some base
>>>>ÂÂÂÂÂÂÂÂÂÂÂ logical region
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > of memory (like
effectiveAddress)
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > *logicalAddressRegionIndex*Â -
the base logical region of
>>>>ÂÂÂÂÂÂÂÂÂÂÂ memory the
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > above offset if relative to
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > *absoluteMemoryAddress* -
absolute memory address of address
>>>>ÂÂÂÂÂÂÂÂÂÂÂ (physical
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > or virtual, be consistent).Â
Optional, recommended to only be
>>>>ÂÂÂÂÂÂÂÂÂÂÂ included
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > on addresses without
parentIndex.
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > Right now the effectiveAddress
is difficult to use as they
>>>>ÂÂÂÂÂÂÂÂÂÂÂ can not be
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > compared without first
figuring out what they are relative to
>>>>ÂÂÂÂÂÂÂÂÂÂÂ and it
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > isn't clear if the effective
address is relative to something
>>>>ÂÂÂÂÂÂÂÂÂÂÂ or absolute.
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > Jim
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > On 4/28/19 2:25 PM, Larry
Golding (Myriad Consulting Inc) wrote:
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > I created and pushed a change
draft for Issue #401
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>ÂÂÂÂÂÂÂÂÂÂÂ
>>>> i
>>>>
thub.com%2Foasis-tcs%2Fsarif-spec%2Fissues%2F401&data="">
>>>> v
>>>>
-lgold%40microsoft.com%7C3a358594051044a5cc8c08d6ccebcbd4%7C72f988bf
>>>> 8
>>>>
6f141af91ab2d7cd011db47%7C1&sdata=o%2Byx6gbIUCCUQ7OgXZNVbNIvLS%2
>>>> B
>>>> DZcMWuzYh9MyTpBs%3D&reserved=0
>>>>ÂÂÂÂÂÂÂÂÂÂÂ
>>>> i
>>>> t
>>>>
hub.com%2Foasis-tcs%2Fsarif-spec%2Fissues%2F401&data="">
>>>> -
>>>> l
>>>>
gold%40microsoft.com%7C3ba2a548e31a4e76386308d6cce9d65e%7C72f988bf86
>>>> f
>>>> 1
>>>>
41af91ab2d7cd011db47%7C1&sdata=SE%2FPLP2Qp3IqObj15smZYfpuMt%2F4Q
>>>> 8
>>>> W
>>>> %2FtjZHO9R4j2M%3D&reserved=0>>,
>>>>
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > âImproved address object
designâ.
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>ÂÂÂÂÂÂÂÂÂÂÂ
>>>> t
>>>>
hub.com%2Foasis-tcs%2Fsarif-spec%2Fblob%2Fmaster%2FDocuments%2FChang
>>>> e
>>>>
Drafts%2FAccepted%2Fsarif-v2.0-issue-401-address-rework.docx&dat
>>>> a
>>>>
=01%7C01%7Cv-lgold%40microsoft.com%7C3a358594051044a5cc8c08d6ccebcbd
>>>> 4
>>>>
%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=p5cZhTJryX9qei56A2
>>>> L
>>>>
9IPvctCF7H4ky6OUhR1yA%2Fbc%3D&reserved=0
>>>>ÂÂÂÂÂÂÂÂÂÂÂ
>>>> i
>>>> t
>>>>
hub.com%2Foasis-tcs%2Fsarif-spec%2Fblob%2Fmaster%2FDocuments%2FChang
>>>> e
>>>> D
>>>>
rafts%2FAccepted%2Fsarif-v2.0-issue-401-address-rework.docx&data
>>>> =
>>>> 0
>>>>
1%7C01%7Cv-lgold%40microsoft.com%7C3ba2a548e31a4e76386308d6cce9d65e%
>>>> 7
>>>> C
>>>>
72f988bf86f141af91ab2d7cd011db47%7C1&sdata=F%2BkR%2BztoJ8h3YQjff
>>>> o %
2FFe7RJ29KWFuTY%2F3kp%2FCX3Wms%3D&reserved=0>
>>>>
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>ÂÂÂÂÂÂÂÂÂÂÂ
>>>> i
>>>>
thub.com%2Foasis-tcs%2Fsarif-spec%2Fblob%2Fmaster%2FDocuments%2FChan
>>>> g
>>>>
eDrafts%2FAccepted%2Fsarif-v2.0-issue-401-address-rework.docx&da
>>>> t
>>>>
a=01%7C01%7Cv-lgold%40microsoft.com%7C3a358594051044a5cc8c08d6ccebcb
>>>> d
>>>>
4%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=p5cZhTJryX9qei56A
>>>> 2
>>>>
L9IPvctCF7H4ky6OUhR1yA%2Fbc%3D&reserved=0
>>>>ÂÂÂÂÂÂÂÂÂÂÂ
>>>> i
>>>> t
>>>>
hub.com%2Foasis-tcs%2Fsarif-spec%2Fblob%2Fmaster%2FDocuments%2FChang
>>>> e
>>>> D
>>>>
rafts%2FAccepted%2Fsarif-v2.0-issue-401-address-rework.docx&data
>>>> =
>>>> 0
>>>>
1%7C01%7Cv-lgold%40microsoft.com%7C3ba2a548e31a4e76386308d6cce9d65e%
>>>> 7
>>>> C
>>>>
72f988bf86f141af91ab2d7cd011db47%7C1&sdata=F%2BkR%2BztoJ8h3YQjff
>>>> o %
2FFe7RJ29KWFuTY%2F3kp%2FCX3Wms%3D&reserved=0>>
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > The original design was
ambiguous about what address.offset
>>>>ÂÂÂÂÂÂÂÂÂÂÂ was based
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > on: the parent object, or
address.baseAddress?
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >ÂÂ * We renamed offset to
offsetFromParent to clear up that
>>>>ÂÂÂÂÂÂÂÂÂÂÂ ambiguity.
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >ÂÂ * We removed baseAddress
because once itâs clear that
>>>>ÂÂÂÂÂÂÂÂÂÂÂ âoffsetâ is
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >ÂÂÂÂ based on the parent
object, thereâs no need to
>>>> duplicate the
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >ÂÂÂÂ information in the child
object.
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >ÂÂ * We added some more kind
values ("header", "table") and we
>>>>ÂÂÂÂÂÂÂÂÂÂÂ (really
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >ÂÂÂÂ Michael) made the
definitions of "section" and
>>>> "segment" more
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >ÂÂÂÂ precise. We (this time,
really me ð) also added text
>>>>ÂÂÂÂÂÂÂÂÂÂÂ acknowledging
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >ÂÂÂÂ that the meanings of these
terms are OS-dependent, and
>>>>ÂÂÂÂÂÂÂÂÂÂÂ recommending
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >ÂÂÂÂ that SARIF producers use
the term most appropriate for
>>>>ÂÂÂÂÂÂÂÂÂÂÂ the target OS.
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >ÂÂ * Finally, an innovation: we
introduced a property
>>>>ÂÂÂÂÂÂÂÂÂÂÂ effectiveAddress,
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >ÂÂÂÂ which, when not present,
can in certain circumstances be
>>>>ÂÂÂÂÂÂÂÂÂÂÂ calculated
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >ÂÂÂÂ by adding the offsets all
the way up the ancestor
>>>> chain. (The
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >ÂÂÂÂ precise algorithm is in
the spec.) This has two benefits:
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >ÂÂÂÂÂÂ o It allows the consumer
to see the final address
>>>>ÂÂÂÂÂÂÂÂÂÂÂ without having
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >ÂÂÂÂÂÂÂÂ to walk all the way up
the ancestor chain. This at
>>>>ÂÂÂÂÂÂÂÂÂÂÂ first /seems/
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >ÂÂÂÂÂÂÂÂ duplicative in the
same way that baseAddress was
>>>>ÂÂÂÂÂÂÂÂÂÂÂ (although even
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >ÂÂÂÂÂÂÂÂ if that were true,
effectiveAddress saves the
>>>>ÂÂÂÂÂÂÂÂÂÂÂ consumer more work
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >ÂÂÂÂÂÂÂÂ than baseAddress did
because baseAddress duplicated
>>>>ÂÂÂÂÂÂÂÂÂÂÂ information
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >ÂÂÂÂÂÂ ÂÂin a /single/ address
object rather than a whole
>>>>ÂÂÂÂÂÂÂÂÂÂÂ chain of them).
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >ÂÂÂÂÂÂÂÂ *BUT!* Itâs not really
duplicative, becauseâ
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >ÂÂÂÂÂÂ o The effectiveAddress
property allows a consumer to
>>>>ÂÂÂÂÂÂÂÂÂÂÂ see the final
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >ÂÂÂÂÂÂÂÂ address /even if some
of the information required to
>>>>ÂÂÂÂÂÂÂÂÂÂÂ calculate
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >ÂÂÂÂÂÂÂÂ it is missing from the
ancestor addresses/. This
>>>>ÂÂÂÂÂÂÂÂÂÂÂ allows you to
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >ÂÂÂÂÂÂÂÂ say, for example,
âHere is the address of this entry
>>>>ÂÂÂÂÂÂÂÂÂÂÂ in the
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >ÂÂÂÂÂÂÂÂ exception handler
table; the table entry is a child
>>>>ÂÂÂÂÂÂÂÂÂÂÂ of the
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >ÂÂÂÂÂÂÂÂ table, which is itself
a child of some other thingâ â
>>>>ÂÂÂÂÂÂÂÂÂÂÂ without
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >ÂÂÂÂÂÂÂÂ having to specify the
address of the exception
>>>>ÂÂÂÂÂÂÂÂÂÂÂ handler table if
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >ÂÂÂÂÂÂÂÂ you donât think thatâs
relevant.
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > This draft also includes a
small amount of residual editorial
>>>>ÂÂÂÂÂÂÂÂÂÂÂ feedback.
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > As always, the provisional
draft and its HTML version are up
>>>>ÂÂÂÂÂÂÂÂÂÂÂ to date:
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>ÂÂÂÂÂÂÂÂÂÂÂ
>>>> t
>>>>
hub.com%2Foasis-tcs%2Fsarif-spec%2Fblob%2Fmaster%2FDocuments%2FProvi
>>>> s
>>>>
ionalDrafts%2Fsarif-v2.0-csd02-provisional.docx&data="">
>>>> -
>>>>
lgold%40microsoft.com%7C3a358594051044a5cc8c08d6ccebcbd4%7C72f988bf8
>>>> 6
>>>>
f141af91ab2d7cd011db47%7C1&sdata=2kOwsLXf72weOgkG6radGIfyUx3LI4l
>>>> c
>>>> eaCvCj4IhlU%3D&reserved=0
>>>>ÂÂÂÂÂÂÂÂÂÂÂ
>>>> i
>>>> t
>>>>
hub.com%2Foasis-tcs%2Fsarif-spec%2Fblob%2Fmaster%2FDocuments%2FProvi
>>>> s
>>>> i
>>>>
onalDrafts%2Fsarif-v2.0-csd02-provisional.docx&data="">
>>>> l
>>>> g
>>>>
old%40microsoft.com%7C3ba2a548e31a4e76386308d6cce9d65e%7C72f988bf86f
>>>> 1
>>>> 4
>>>>
1af91ab2d7cd011db47%7C1&sdata=rXmV0TaOBGM5HXwuXXIN%2FnBWgU4yL5Kj
>>>> A
>>>> 3
>>>> pFRoF9884%3D&reserved=0>
>>>>
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>ÂÂÂÂÂÂÂÂÂÂÂ
>>>> i
>>>>
thub.com%2Foasis-tcs%2Fsarif-spec%2Fblob%2Fmaster%2FDocuments%2FProv
>>>> i
>>>>
sionalDrafts%2Fsarif-v2.0-csd02-provisional.docx&data="">
>>>> v
>>>>
-lgold%40microsoft.com%7C3a358594051044a5cc8c08d6ccebcbd4%7C72f988bf
>>>> 8
>>>>
6f141af91ab2d7cd011db47%7C1&sdata=2kOwsLXf72weOgkG6radGIfyUx3LI4
>>>> l
>>>> ceaCvCj4IhlU%3D&reserved=0
>>>>ÂÂÂÂÂÂÂÂÂÂÂ
>>>> i
>>>> t
>>>>
hub.com%2Foasis-tcs%2Fsarif-spec%2Fblob%2Fmaster%2FDocuments%2FProvi
>>>> s
>>>> i
>>>>
onalDrafts%2Fsarif-v2.0-csd02-provisional.docx&data="">
>>>> l
>>>> g
>>>>
old%40microsoft.com%7C3ba2a548e31a4e76386308d6cce9d65e%7C72f988bf86f
>>>> 1
>>>> 4
>>>>
1af91ab2d7cd011db47%7C1&sdata=rXmV0TaOBGM5HXwuXXIN%2FnBWgU4yL5Kj
>>>> A
>>>> 3
>>>> pFRoF9884%3D&reserved=0>>
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>ÂÂÂÂÂÂÂÂÂÂÂ
>>>> t
>>>>
hub.com%2Foasis-tcs%2Fsarif-spec%2Fblob%2Fmaster%2FDocuments%2FProvi
>>>> s
>>>>
ionalDrafts%2Fsarif-v2.0-csd02-provisional.htm&data="">
>>>> l
>>>>
gold%40microsoft.com%7C3a358594051044a5cc8c08d6ccebcbd4%7C72f988bf86
>>>> f
>>>>
141af91ab2d7cd011db47%7C1&sdata=M6Bu4wm4oJJKCTnMCfpdnCgBnGSWOTx3
>>>> t
>>>> nDnUmUZB2Q%3D&reserved=0
>>>>ÂÂÂÂÂÂÂÂÂÂÂ
>>>> i
>>>> t
>>>>
hub.com%2Foasis-tcs%2Fsarif-spec%2Fblob%2Fmaster%2FDocuments%2FProvi
>>>> s
>>>> i
>>>>
onalDrafts%2Fsarif-v2.0-csd02-provisional.htm&data="">
>>>> g
>>>> o
>>>>
ld%40microsoft.com%7C3ba2a548e31a4e76386308d6cce9d65e%7C72f988bf86f1
>>>> 4
>>>> 1
>>>>
af91ab2d7cd011db47%7C1&sdata=U%2BKe7uU1NF%2BDoIiuMBxxLIvQK%2BSBq
>>>> I
>>>> P
>>>> lbhHLSJ689r4%3D&reserved=0>
>>>>
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>ÂÂÂÂÂÂÂÂÂÂÂ
>>>> i
>>>>
thub.com%2Foasis-tcs%2Fsarif-spec%2Fblob%2Fmaster%2FDocuments%2FProv
>>>> i
>>>>
sionalDrafts%2Fsarif-v2.0-csd02-provisional.htm&data="">
>>>> -
>>>>
lgold%40microsoft.com%7C3a358594051044a5cc8c08d6ccebcbd4%7C72f988bf8
>>>> 6
>>>>
f141af91ab2d7cd011db47%7C1&sdata=M6Bu4wm4oJJKCTnMCfpdnCgBnGSWOTx
>>>> 3
>>>> tnDnUmUZB2Q%3D&reserved=0
>>>>ÂÂÂÂÂÂÂÂÂÂÂ
>>>> i
>>>> t
>>>>
hub.com%2Foasis-tcs%2Fsarif-spec%2Fblob%2Fmaster%2FDocuments%2FProvi
>>>> s
>>>> i
>>>>
onalDrafts%2Fsarif-v2.0-csd02-provisional.htm&data="">
>>>> g
>>>> o
>>>>
ld%40microsoft.com%7C3ba2a548e31a4e76386308d6cce9d65e%7C72f988bf86f1
>>>> 4
>>>> 1
>>>>
af91ab2d7cd011db47%7C1&sdata=U%2BKe7uU1NF%2BDoIiuMBxxLIvQK%2BSBq
>>>> I
>>>> P
>>>> lbhHLSJ689r4%3D&reserved=0>>
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > *Please take a look.* We still
plan to open the CSD 2 ballot
>>>>ÂÂÂÂÂÂÂÂÂÂÂ on Monday.
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > Thanks,
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ > Larry
>>>>
>>>>ÂÂÂÂÂÂÂÂÂÂÂÂ >
>>>>
--
Paul Anderson, VP of Engineering, GrammaTech, Inc.
531 Esty St., Ithaca, NY 14850