Re: c-stack vs. older platforms

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

Re: determining the stack bounds

Bruno Haible clisp.org> writes: > > Eric Blake wrote: > > user_context->uc_stack.ss_sp contains the location > > of the currently running (alternate) stack, not the stack where the fault > > occurred. ... find out where the _original_ stack ended I'm not sure if it is a bug or intentional t

Re: determining the stack bounds

Eric Blake wrote: > user_context->uc_stack.ss_sp contains the location > of the currently running (alternate) stack, not the stack where the fault > occurred. ... find out where the _original_ stack ended > ... > I haven't looked at how libsigsegv handles this situation libsigsegv has a soluti

Re: libsigsegv questions

[switching to bug-gnulib] Eric Blake wrote in : > When I get around to dumping m4's own stackovf.c and > replacing it with libsigsegv when available, and gnulib's c-stack when the > external library is not present, I will stick

Re: c-stack vs. older platforms

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

Re: c-stack vs. older platforms

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

Re: c-stack vs. older platforms

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

Re: c-stack vs. older platforms

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

Re: [PATCH 2/2] Add missing argz_* functions from glibc

Jim Meyering <[EMAIL PROTECTED]> wrote: > In the mean time, I'm going to check in the new generated files in an > hour or two. So if anyone has an objection, speak up soon. > Lower priority: I'll look into automating the procedure > to generate these files. As for generating the files, with the p

c-stack vs. older platforms

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

Re: [PATCH 2/2] Add missing argz_* functions from glibc

Eric Blake <[EMAIL PROTECTED]> wrote: > Jim Meyering meyering.net> writes: >> > Yeah, it seems silly to test for all of them; wouldn't it make sense to >> > check for just one of them (the last one added) ? >> >> argz_replace is the one with the most recent first log entry: > > For glibc. On cygw