sarif — archive

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

From: Laurence Golding
To: [email protected]
Date: Mon, 29 Apr 2019 21:29:00 -0000

I m going to go with the Nullables then, as it is consistent with Jim s original proposal. He didn t add relativeToAddressIndex because he liked it; he did it to try to help out our poor SDK. I was almost done with the draft; I was just waiting for this to resolve. I ll push the draft in about half an hour and we should be good to go. Larry From: Michael Fanning <[email protected]> Sent: Monday, April 29, 2019 2:26 PM To: Larry Golding (Myriad Consulting Inc) <[email protected]>; James Kupsch <[email protected]>; OASIS SARIF TC Discussion List <[email protected]> Subject: RE: [sarif] #401: Improved design of address object design Yes, I think we should be ready to just embrace a schema that requires a nullable type in C#. The specific proposal, when offsetFromParent or relativeAddress are _ absent _, they are truly absent and cannot be consumed. When populated, whether negative, 0 or positive value, those values are honored. This is very clear, doesn t require a new property, and comes at the small expense of requiring nullable types in the C# SDK. Michael From: Larry Golding (Myriad Consulting Inc) < [email protected] > Sent: Monday, April 29, 2019 2:24 PM To: James Kupsch < [email protected] >; Michael Fanning < [email protected] >; OASIS SARIF TC Discussion List < [email protected] > Subject: RE: [sarif] #401: Improved design of address object design 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 address object 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 address object MAY contain a property named relativeAddress whose value is an integer containing the relative address (see 3.32.4) of thisObject . If parentIndex is absent, then relativeAddress SHALL be absent. If relativeAddress is 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, relativeAddress can 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 parentIndex is 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] <[email protected]> On Behalf Of Larry Golding (Myriad Consulting Inc) Sent: Monday, April 29, 2019 12:59 PM To: Michael Fanning <[email protected]> ; James Kupsch <[email protected]> ; OASIS SARIF TC Discussion List <[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] > Sent: Monday, April 29, 2019 12:56 PM To: James Kupsch < [email protected] >; Larry Golding (Myriad Consulting Inc) < [email protected] >; OASIS SARIF TC Discussion List < [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.