sarif — archive

Re: [sarif] #401: Improved design of address object design

From: Jim Kupsch
To: [email protected]
Date: Mon, 29 Apr 2019 21:30:00 -0000

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 <[email protected]> > *Sent:* Monday, April 29, 2019 2:19 PM > *To:* Larry Golding (Myriad Consulting Inc) <[email protected]>; > Michael Fanning <[email protected]>; OASIS SARIF TC > Discussion List <[email protected]> > *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:*[email protected] > < mailto:[email protected] > <[email protected]> > < mailto:[email protected] > *On Behalf Of *Larry Golding > (Myriad Consulting Inc) > *Sent:* Monday, April 29, 2019 12:59 PM > *To:* Michael Fanning <[email protected]> > < mailto:[email protected] >; James Kupsch > <[email protected]> < mailto:[email protected] >; OASIS SARIF TC > Discussion List <[email protected]> > < mailto:[email protected] > > *Subject:* RE: [sarif] #401: Improved design of address object design > > I approve this message! Much better than my solution. > > *From:*Michael Fanning <[email protected] > < mailto:[email protected] >> > *Sent:* Monday, April 29, 2019 12:56 PM > *To:* James Kupsch <[email protected] < mailto:[email protected] >>; > Larry Golding (Myriad Consulting Inc) <[email protected] > < mailto:[email protected] >>; OASIS SARIF TC Discussion List > <[email protected] < mailto:[email protected] >> > *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 > > *From:*James Kupsch <[email protected] < mailto:[email protected] >> > *Sent:* Monday, April 29, 2019 12:46 PM > *To:* Larry Golding (Myriad Consulting Inc) <[email protected] > < mailto:[email protected] >>; Michael Fanning > <[email protected] > < mailto:[email protected] >>; OASIS SARIF TC Discussion > List <[email protected] < mailto:[email protected] >> > *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. > > *From:* [email protected] > < mailto:[email protected] > <[email protected]> > < mailto:[email protected] > *On Behalf Of *Larry Golding > (Myriad Consulting Inc) > *Sent:* Monday, April 29, 2019 11:46 AM > *To:* James Kupsch <[email protected]> > < mailto:[email protected] >; Michael Fanning > <[email protected]> > < mailto:[email protected] >; OASIS SARIF TC > Discussion List <[email protected]> > < mailto:[email protected] > > *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 > *To:* James Kupsch <[email protected] > < mailto:[email protected] >>; Michael Fanning > <[email protected] > < mailto:[email protected] >>; OASIS SARIF TC > Discussion List <[email protected] > < mailto:[email protected] >> > *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 > >