[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SIGSTKSZ is now a run-time variable

From: Eric Blake
Subject: Re: SIGSTKSZ is now a run-time variable
Date: Tue, 9 Mar 2021 09:40:59 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0

[adding bug-gnulib]

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

Only when sticking strictly to POSIX.  Reading the glibc NEWS more closely,

  _GNU_SOURCE are defined, MINSIGSTKSZ and SIGSTKSZ are no longer
  constant on Linux.  MINSIGSTKSZ is redefined to sysconf(_SC_MINSIGSTKSZ)
  and SIGSTKSZ is redefined to sysconf (_SC_SIGSTKSZ).

which means you only have a non-constant SIGSTKSZ when _explicitly_
asking for non-POSIX extensions by setting _GNU_SOURCE; but since most
gnulib projects (including m4) indeed request _GNU_SOURCE, we can no
longer rely on the POSIX definition.

>> Please advise how I can get past this.
> Fix your <signal.h>.

We're going to need to fix gnulib instead, and then release an updated
m4 built with a newer gnulib.

> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]