Re: SIGSTKSZ is now a run-time variable
Eric Blake via Libc-alpha <[email protected]>
| Newsgroups | gmane.comp.lib.glibc.alpha,gmane.comp.gnu.m4.bugs,gmane.comp.standards.posix.austin.general |
|---|---|
| Organization | Red Hat, Inc. |
| Message-ID | <[email protected]> |
[adding glibc and Austin group lists] On 3/6/21 12:50 PM, Bruno Haible 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. The question becomes whether glibc is in violation of POSIX for having made the change, or whether POSIX needs to be amended to allow SIGSTKSZ to be non-preprocessor-safe and/or non-constant. > > 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>. https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=6c57d320484988e87e446e2e60ce42816bf51d53 shows where glibc made the change, and I've now seen reports of several projects failing to build when using glibc with this change included. > > Bruno > > [1] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html > > -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org