Re: Mandatory stack check (was: Changing discriminants...)

[bobduff@world.std.com (Robert A Duff)]

In article <320F0DD1.7A66@lmtas.lmco.com>,
Ken Garlington  <garlingtonke@lmtas.lmco.com> wrote:
>Does this mean that the check could be suppressed on CPUs that didn't have
>this feature? If so, then I wouldn't see a problem.

I'm not sure what you're asking.  Yes, you can suppress the checks.
Whether or not the implementation actually does anything about it, is up
to the implementation.  As Robert explained, GNAT doesn't do these
checks at all (yet) on most targets, so there's nothing to suppress.

I don't know if GNAT runs on any CPU's that don't have hardware memory
mapping support.

>I assume also that the stacks have to be aligned on a page boundary. Is this
>automatic in GNAT?

Probably.

>Just out of curiosity, how is the heap checked?

That's typically done using explicit code, I think.  As usual, I'm not
talking about GNAT in particlar here -- just what I know about how these
things are done in various compilers.

>2. Even if there is a possibility of stack overflow, if you are using
>hardware mechanisms to implement stack checks (no software involved),
>you can usually do a global-level analysis to show that the hardware
>mechanism will work reliably.

You can easily show that the mechanism jumps to the handler it's
supposed to, and cleans up the stack properly.  However, it seems to me
that it's a bit harder to prove anything about what that handler code
does -- its precondition is essentially "false".  That is, the handler
can't assume much of anything about the state of the program variables.
I suppose it could just zero memory and start the program over, which
might be appropriate in *some* cases.

>Of course, if there's _nothing_ you can do to handle Storage_Error, then
>why have code lurking in your application that raises it (possibly when
>you _don't_ want it raised)?

Well, there's one thing that you can do -- kill the program.  This is
the default behavior, and for most programs, is vastly superior to
overwriting random memory and so forth.  For a rocket, though, killing
the program and overwriting memory might well both be unacceptable.

- Bob