You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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:
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:
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: