Comment 27 for bug 1757517

I'm assigning this issue to myself since it seems that nptl/allocatestack.c and nptl/nptl-ini.c need cleanup regarding the definition of stack.

The fact that POSIX has a seperate set of functions for getting and setting the guard size indicates that the guard is *not* considered a part of the stack. Not to mention the POSIX wording "the implementation allocates extra memory" means that the current GLIBC implementation isn't correct (but one or two pages doesn't help here). The guard size should be removed from the stack computation.

Given that the guard size shouldn't be part of the stack size brings even more doubt on the current practice of placing the static tls and pthread descriptor into the stack.

Yet another corner case is that using PTHREAD_STACK_MIN as a minimal stack should get you a thread that starts, but under a system where a variable sized TLS data region is included you are not guaranteed this at all. In fact using PTHREAD_STACK_MIN as a size might or might not work which is in my opinion another failure to meet the principle of "least surprise."

I'm asking for some interpretation help from the Austin Group regarding the meaning of stack.