|
| From: | Blake McBride |
| Subject: | Re: [Bug-apl] Deep Nesting |
| Date: | Mon, 24 Aug 2015 08:47:48 -0500 |
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 <address@hidden> 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 <address@hidden>
> 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
> >
> >
> >
> >
| [Prev in Thread] | Current Thread | [Next in Thread] |