Bruno: Just wanted to add.......glibc has made this change and Not yet released Fedora has made this change among a number of other packages. This is the trend going forward.
Carol On Mon, Mar 8, 2021 at 8:48 AM Carol Bouchard <cbouc...@redhat.com> wrote: > 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 <br...@clisp.org> 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 >> >>
