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 > >
