[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
address object occurs within a
physicalLocation object
thisObject, and if
thisObject.length and
thisObject.address.length are both present, then then
SHALL be equal. As the spec stands, I canât write this because
physicalLocation.length is non-negative. I can add words like this: If an
address object occurs within a
physicalLocation object
thisObject, and if
thisObject.length and
thisObject.address.length are both present, then then
SHALL be equal. In that case, if thisObject.address.length is negative, then
thisObject.length will also be negative. In all other circumstances,
length SHALL be non-negative. Michael, are you ok with that complication? Larry From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org>
On Behalf Of Larry Golding (Myriad Consulting Inc) 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 From: James Kupsch <kupsch@cs.wisc.edu>
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
<sarif@lists.oasis-open.org> On Behalf Of James Kupsch After reading the address section changes. I have a couple of comments: 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, âImproved address object designâ. The original design was ambiguous about what
address.offset was based on: the parent object, or
address.baseAddress?
This draft also includes a small amount of residual editorial feedback. As always, the provisional draft and its HTML version are up to date: https://github.com/oasis-tcs/sarif-spec/blob/master/Documents/ProvisionalDrafts/sarif-v2.0-csd02-provisional.docx Please take a look. We still plan to open the CSD 2 ballot on Monday. Thanks, Larry |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]