Re: SIGSTKSZ is now a run-time variable

Hi Bruno:

This is the direction everyone is going in.  Here is an example of changes
in glibc.  They're not the
only ones making this change.
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=6c57d320484988e87e446e2e60ce42816bf51d53

Asked why the change? The response we received in regards to the signal
change is as follows:
*We don't have a choice. The old interfaces are simply incompatible with
modern hardware. CPUs have massive register files nowadays. Applications
using minimal signal stacks need to adapt in some way.*

*Carol*

On Sat, Mar 6, 2021 at 1:53 PM Bruno Haible <[email protected]> wrote:

> Hi,
>
> Carol Bouchard wrote in <
> https://lists.gnu.org/archive/html/bug-m4/2021-03/msg00000.html>:
> > A change that was introduced is the
> > #define SIGSTKSZ is no longer a statically defined variable.  It's value
> can
> > only be determined at run time.
> >
> > # define SIGSTKSZ sysconf (_SC_SIGSTKSZ)
>
> This is invalid. POSIX:2018 [1] defines two lists of macros:
>
>   1) "The <signal.h> header shall define the following macros which shall
>       expand to integer constant expressions that need not be usable in
>       #if preprocessing directives:"
>
>   2) "The <signal.h> header shall also define the following symbolic
> constants:"
>
> SIGSTKSZ is in the second list. This implies that it must expand to a
> constant
> and that it must be usable in #if preprocessing directives.
>
> Besides being invalid, it is also not needed. The alternate signal stack
> needs to be dimensioned according to the CPU and ABI that is in use. For
> example,
> SPARC processors tend to use much more stack space than x86 per function
> invocation. Similarly, 64-bit execution on a bi-arch CPU tends to use more
> stack
> space than 32-bit execution, because return addresses and other pointers
> are
> 64-bit vs. 32-bit large. But once you have fixed the CPU and the ABI,
> there is
> no ambiguity any more.
>
> > This affects m4 code since the code assumes a statically defined
> variable which
> > can be determined at preprocessor time.
>
> POSIX guarantees this assumption.
>
> > Please advise how I can get past this.
>
> Fix your <signal.h>.
>
> Bruno
>
> [1]
> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html
>
>