I agree! Thank you! On Mon, Aug 24, 2015 at 8:41 AM, Juergen Sauermann < [email protected]> wrote:
> 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 <[email protected]> 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 <[email protected]> >> > 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 >> > > >> > > >> > > >> > > >> > > >
