Re: SIGSTKSZ is now a run-time variable

[shwaresyst]

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