To me that looks like a conformance violation and should be reverted. There is no _SC_SIGSTKSZ defined in <unistd.h> by the standard, to begin with, so that use of sysconf() is a non-portable extension on its own.
I could see the definition of SIGSTKSZ being changed to the static minimum a particular processor requires, or is initially allocated as a 'safe' amount, rather than static "default size", and moving SIGSTKSZ to <limits.h>. This would contrast to MINSIGSTKSZ as the lowest value for a platform for all supported processors. Then an application could use sysconf() to query for the maximum size the configuration supports if it wants to use more than that, as a runtime increasable limit. On Tuesday, March 9, 2021 Eric Blake via austin-group-l at The Open Group <ebl...@redhat.com> wrote: [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
