OASIS Static Analysis Results Interchange Format (SARIF) TC

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. ð > > 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 <kupsch@cs.wisc.edu < mailto:kupsch@cs.wisc.edu >> > *Sent:* Monday, April 29, 2019 12:46 PM > *To:* Larry Golding (Myriad Consulting Inc) <v-lgold@microsoft.com > < mailto:v-lgold@microsoft.com >>; Michael Fanning > <Michael.Fanning@microsoft.com > < mailto:Michael.Fanning@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 > > 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:* 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 11:46 AM > *To:* James Kupsch <kupsch@cs.wisc.edu> > < mailto:kupsch@cs.wisc.edu >; Michael Fanning > <Michael.Fanning@microsoft.com> > < mailto:Michael.Fanning@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 > *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 <kupsch@cs.wisc.edu > < mailto:kupsch@cs.wisc.edu >>; Michael Fanning > <Michael.Fanning@microsoft.com > < mailto:Michael.Fanning@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 > > 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 > >

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. ð > > 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 <kupsch@cs.wisc.edu < mailto:kupsch@cs.wisc.edu >> > *Sent:* Monday, April 29, 2019 12:46 PM > *To:* Larry Golding (Myriad Consulting Inc) <v-lgold@microsoft.com > < mailto:v-lgold@microsoft.com >>; Michael Fanning > <Michael.Fanning@microsoft.com > < mailto:Michael.Fanning@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 > > 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:* 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 11:46 AM > *To:* James Kupsch <kupsch@cs.wisc.edu> > < mailto:kupsch@cs.wisc.edu >; Michael Fanning > <Michael.Fanning@microsoft.com> > < mailto:Michael.Fanning@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 > *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 <kupsch@cs.wisc.edu > < mailto:kupsch@cs.wisc.edu >>; Michael Fanning > <Michael.Fanning@microsoft.com > < mailto:Michael.Fanning@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 > > 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 > >