MINSIGSTKSZ
is no longer a constant
#3299
Labels
breakage-candidate
C-bug
Category: bug
E-medium
E-medium Call for participation: Medium difficulty. Experience needed to fix: Intermediate.
Milestone
Same with SIGSTKSZ.
This starts with a more philosophical problem: glibc 2.34 defines these macros as expanding to an expression that resolves as a dynamic, non-constant value. This addresses the fact that, from glibc's perspective, and indeed for any libc that wants to support a vast array of architectures, they are non-constant values. See:
https://sourceware.org/glibc/wiki/Release/2.34#Non-constant_MINSIGSTKSZ_and_SIGSTKSZ
The reason is that MINSIGSTKSZ can either be so huge that it effectively rules out some hardware that currently can run glibc-based programs, or it can be non-constant. As glibc chose the latter route, it might be useful to contrast with a libc that chose the former route, Darwin:
However, the previous constant can be useful in actual programs if taken as somewhere close to a "floor", e.g. see:
The more practical issue that spawns out of this: if this value is incorrect, it can easily lead to data corruption. Huge amounts of hardware state may potentially need to be managed by a signal handler, and clobbering user data is unacceptable.
The text was updated successfully, but these errors were encountered: