enh <[email protected]> wrote: > we had the same issue in bionic when we removed all our alloca()s, modulo the > fact > that ours is a VLA rather than alloca(), but same thing: > https://android.googlesource.com/platform/bionic/+/master/libc/bionic/exec.cpp#61
that cargo culting doesn't fix anything... > we argued that it doesn't matter in this case though because we'll touch all > the > entries, in order, so there's no possibility of jumping off the end of the > stack onto > another VMA. we've always had a sufficient gap beyond the end of our stack, but a few years ago many people freaked out because they didn't. nowadays, that is enforced on a system level, so that door is largely closed, dependent on linear access. > (we have used mmap() instead in more complicated cases though.) yes, that is the solution, but rollback and errno must be handled carefully. If this mmap() fix goes in, the only alloca() remain in our tree are: clang - seems to be in test code only binutils - shocking 1 in gcc configure 1 in perl - non-openbsd cases 1 small one in libcrypto - someone should go fix that
