[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SIGSTKSZ is now a run-time variable
From: |
Bruno Haible |
Subject: |
Re: SIGSTKSZ is now a run-time variable |
Date: |
Sat, 06 Mar 2021 19:50:26 +0100 |
User-agent: |
KMail/5.1.3 (Linux/4.4.0-203-generic; KDE/5.18.0; x86_64; ; ) |
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
- SIGSTKSZ is now a run-time variable, Carol Bouchard, 2021/03/04
- Re: SIGSTKSZ is now a run-time variable,
Bruno Haible <=
- Re: SIGSTKSZ is now a run-time variable, Carol Bouchard, 2021/03/08
- Re: SIGSTKSZ is now a run-time variable, Eric Blake, 2021/03/09
- Re: SIGSTKSZ is now a run-time variable, Andreas Schwab, 2021/03/09
- Re: SIGSTKSZ is now a run-time variable, Eric Blake, 2021/03/09
- Re: SIGSTKSZ is now a run-time variable, Bruno Haible, 2021/03/09
- Re: SIGSTKSZ is now a run-time variable, H.J. Lu, 2021/03/09
- Re: SIGSTKSZ is now a run-time variable, Scott Lurndal, 2021/03/09
- Re: SIGSTKSZ is now a run-time variable, Carol Bouchard, 2021/03/16
- Re: SIGSTKSZ is now a run-time variable, Carol Bouchard, 2021/03/26