Skip to content

MINSIGSTKSZ is no longer a constant #3299

Open
@workingjubilee

Description

@workingjubilee

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:

#define MINSIGSTKSZ     32768   /* (32K)minimum allowable stack */
#define SIGSTKSZ        131072  /* (128K)recommended stack size */

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-bugCategory: bugE-mediumE-medium Call for participation: Medium difficulty. Experience needed to fix: Intermediate.breakage-candidate

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions