Eric Blake byu.net> writes:
> > - sigaltstack is present and works on
> > Linux, FreeBSD, NetBSD, AIX, HP-UX 11.11, IRIX, OSF/1, Solaris, and
> > (more or less) MacOS X.
> > It is not available on
> > OpenBSD, HP-UX 11.23, Cygwin, mingw, BeOS.
>
> Actually, sigaltstack is
Eric Blake byu.net> writes:
> and Linux glibc 2.3.4, I noticed that config.h's
and kernel 2.6.9,
> HAVE_XSI_STACK_OVERFLOW_HEURISTIC was undefined with c-stack, so it seems
like
> _any_ segv, rather than true overflows, would be reported on those platforms
(I
> guess I'll have to enhance a
Bruno Haible clisp.org> writes:
> > are there any platforms where switching to c-stack would cause a
> > regression in m4's stack detection abilities if we don't port m4's
fallbacks
> > for supporting older APIs?
> >
> > [1]http://git.savannah.gnu.org/gitweb/?p=m4.git;a=blob;f=src/stackovf.c
Eric Blake wrote:
> I'm wondering whether there are any current porting
> targets where m4's attempts to use the fallbacks of sigstack in place of
> missing sigaltstack, and/or sigvec/SV_ONSTACK in place of missing
> sigaction/SA_ONSTACK, are worth porting into the c-stack module. Or put
> ano
Eric Blake <[EMAIL PROTECTED]> writes:
> are there any platforms where switching to c-stack would cause a
> regression in m4's stack detection abilities if we don't port m4's fallbacks
> for supporting older APIs?
I'm sure there are. Bruno has documented several in the past.
However, at this p
I'm considering abandoning m4's stack overflow detector[1] (first written in
Apr 94) with gnulib's c-stack module (first written for diffutils in Feb 02)
because m4's version does not obey signal safety rules. Also, I've noticed
m4's version tends to misdiagnose failure on Linux and dump core r
