https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87220
--- Comment #11 from Rich Felker <bugdal at aerifal dot cx> --- This problem starded because I read "not generally sufficient" in the sense that it's helpful but not a complete fix for the kinds of issues that -fstack-clash-protection mitigates. Based on my findings and followup discussion, I think it's not even helpful, and I wonder why glibc is supporting it for this use (separate topic of course, but it indicates there's a misunderstanding of its intended and real capabilities, I think). Regarding: > Well, that's implicit, if you want to detect stack overflow, you need to > compile the entire software with stack checking, whatever the implementation > method. I don't see that as implicit, and it's certainly not true for -fstack-clash-protection. Callers that know they have large stacks but don't use them can of course call into dubious code that might try to use ridiculous amounts of stack as long as the latter is compiled with stack clash protection. Likewise (assuming a guard page) a library where all functions have trivial stack usage is safe to call from a caller that may have almost exhausted its stack already, even if the library was not compiled with -fstack-clash-protection.
