bug-m4
[Top][All Lists]
Advanced

[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




reply via email to

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