Re: [Bug-apl] Deep Nesting

[Juergen Sauermann]

Hi, the segfault thrown by this stack limit is not caught even though GNU APL installs signal handlers for SIGSEGV. Therefore anything based on evaluating the arguments of the signal handler would not work. The alternative of checking beforehand has (negative) runtime implications and apparently portability issues. I therefore believe that this type of error is so uncommon that we should not handle it. I made a simple test with good old bash in a xterm with recursive call to itself: source ./qqq  # qqq is a text file containing only this line A short moment and this does not only crash (in a nice way like throwing a segfault), but kills the xterm with it. In other words, the behaviour of processes when they reach there limits is fairly unpredictable anyhow. As a consequence, I believe it is better to leave things as they are. /// Jürgen On 08/23/2015 07:18 PM, Blake McBride wrote: What I detest is trying to build a package that hasn't been built in a while only to find that the author insisted on using a few system-dependent facilities that render what could have been portable into a bloody nightmare.  A good example of this is the latest source to Franz Lisp (not the Franz company).  They had something that could have easily been completely portable but rendered it an unusable mess because of a few stupid decisions "in the name of efficiency".  Of course "efficiency" means a whole different thing with current machine speeds.  But - we don't have Franz Lisp anymore. GNU APL will not be maintained forever.  Years after it has cease being maintained, people will want to build it and take a look at this APL thing.  If it won't build pretty easily, they'll just toss it out.  Making it portable, with #ifdef's if necessary, is important. Speaking for myself, I stopped using APL for 25+ years because I didn't want to use something associated with a company or set of companies that could disappear tomorrow.  I didn't want to waste all of my effort.  Now we have GNU APL, and with it, a promise of vendor independence.  As soon as you stick in a bunch of machine specifics, all the benefit disappears for me. Lastly, with 35 years C experience, I feel strongly that #ifdef's have their place. Blake McBride   On Sun, Aug 23, 2015 at 11:44 AM, fred <fred_wei...@hotmail.com> wrote: Blake You will have to define what "portable C++" means. I don't really think that any of this actually has to do with C++. The method I outlined uses POSIX definitions (and, thus, is, by definition and standardization, "portable"). I even indicated where the method was outside of POSIX definition and scope. What I don't know is the POSIX compliance of the operating environments that you want to be "portable" to/with. However, the technique I outlined is "compatible" with BSD Unix, Linux, Solaris, AIX and HP/UX across a variety of hardware platforms: Intel, Power, Itanium and (I believe) Z-series. What I *don't* know is if Microsoft Windows (in any of it's current incarnations) is included in the compatibility list (and, I suspect, there may be issues because, as far as I know, isn't GNU APL usually built with cygwin or something?). I personally *detest* #ifdef as a platform selection method. FredW On Sun, 2015-08-23 at 10:55 -0500, Blake McBride wrote: > If you do it, please do it in a (#ifdef) way so it can still be built > with > portable C++. > > Thanks! > > Blake > > > On Sun, Aug 23, 2015 at 9:08 AM, fred <fred_wei...@hotmail.com> > wrote: > > > Juergen > > > > Note that stack red-zones are typically already generated. So, you > > don't want to mess with that. The following plan will work in > > conjunction with the system stack red-zone. > > > > What I would do is: > > > > At startup, call down, with a defined limit. Each call level should > > take the local storage that is expected during "normal" calls. If > > this > > fails, the original target could not be achieved anyway. The > > signal() > > handler can be introduced before this is done. If a trap occurs, > > less > > stack nesting can be tried. On the deepest nesting, return a > > pointer to > > a local stack variable. Of course, this pointer cannot be used > > after > > return, but we just want to know the *location* of that memory. > > > > Use mprotect() on that pointer to establish the red page. a SIGSEGV > >  will then be generated if the stack extends to that point. > > signal() > > will capture the SIGSEGV. Use setjmp() and longjmp() to unwind the > > stack after the SIGSEGV. > > > > Now, you want to use sigaction() to supply a sigaction handler, > > which > > gets passed a ucontext_t, which allows access to the actual address > > that caused the fault, the registers, etc. Old POSIX definition had > > it > > defined such that the fault could be processed, and a return from > > the signal handler would restart the instruction. More recent POSIX > > simply marked this as "undefined behaviour". > > > > This will work with both grow-up and grow-down stacks, *and* on > > implementations with "software stack". Eg. should work on Z-series. > > However, it is *not* (and cannot be) POSIX compliant. POSIX only > > allows > > mprotect() on mmap() memory (which is not stack memory). Also, > > POSIX > > specifies that execution becomes undefined after SIGSEGV -- even if > > it > > is caught. I just ignore these issues... (old POSIX, and very > > helpful > > if writing debug routines, and binary translators etc.). > > > > FredW > > > > > > > >