Software Assurance Reference Dataset

[Andrew Godfrey via Digitalmars-d]

On Sunday, 20 July 2014 at 06:06:16 UTC, bearophile wrote:
> Andrew Godfrey:
>
>> 2) Annotations about when a function does not expect 
>> re-entrancy
>> to be possible based on call-graph analysis.
>
> I don't understand. Assuming I know tAhis 
> (http://en.wikipedia.org/wiki/Reentrancy_%28computing%29 ) can 
> you show an example?

Sorry, by "re-entrancy" I just meant a statement
of whether it is possible for the function to be re-entered
(not whether it would be correct to do so).
Thanks for the reminder, so I can exclude the complication
of ISR's from my point.

In the codebase I work on - application code - there
are no ISR's, but a common cause of unexpected re-entrancy we 
have is:
functions that call a Windows API which pumps messages.
This produces unexpectedly deep call stacks and threatens stack 
overflow.

But that's a complicated case that may not be feasible
for the compiler to help with. So, a simpler example...


The general idea here is that you've convinced yourself you
need to do something which stresses usage of stack space,
and you believe it is safe to do because of *something*.
Ideally you can express that "something" so that
if anyone tries to change it later, the compiler catches that.


So, for example you've allocated a buffer on the stack,
and your function 'A' builds up data into it, then calls
another function 'X' to 'send' that data in some way.
Function 'A' definitely doesn't expect to be re-entered.
(It may or may not be re-entrant, in the definition of the wiki 
page.
Doesn't matter for this.)

Now the first step probably doesn't need language help:
call it "assertIAmNotReentered()". I think any solution probably
still needs this as a backup. I say "assert" (i.e. runtime check
that you'd remove in a release build) because I'm assuming
that if you use it a lot you wouldn't want to pay for all those
checks in a release build.


Now: Suppose 'X' is a Phobos function, and 'A' doesn't
call anything else. Then it seems feasible (but a lot of work)
to provide an annotation (or combination of annotations)
that mean:
     "Compiler, I am not called by an ISR. You don't have to verify
     that. But given that, I claim that I am not re-entered.
     Please verify."

This is a lot of work - and potentially error-prone - because
when Phobos calls the C runtime or OS API's, humans
would need to make decisions about whether those functions
'may callback'. For this reason I don't think we'd want
to eliminate "assertIAmNotReentered()".

By this process, Phobos functions which may call a 'callback' 
back into user code (whether directly or indirectly) would be 
distinguished
from ones which cannot (let's call it "NoCallback", since
I can't think of a non-terrible name right now).
And then the annotation above
can be enforced at least in those terms (i.e. the compiler
ensures that 'X' only calls "NoCallback"-annotated functions).


I think this is valuable, and not just to avoid stack overflow.
The message-pumping case often violates higher-level correctness.