From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,b7566e485e23e171 X-Google-Attributes: gid103376,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: Mandatory stack check (was: Changing discriminants...) Date: 1996/08/13 Message-ID: #1/1 X-Deja-AN: 173807946 references: <3209AC29.3E21@lmtas.lmco.com> <320F0DD1.7A66@lmtas.lmco.com> organization: The World Public Access UNIX, Brookline, MA newsgroups: comp.lang.ada Date: 1996-08-13T00:00:00+00:00 List-Id: In article <320F0DD1.7A66@lmtas.lmco.com>, Ken Garlington 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