https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848
--- Comment #20 from Martin Uecker <muecker at gwdg dot de> --- And what alternative do you think is fundamentally safer than VLAs? VLAs know their bound. Thus, they integrate with _FORTIFY_SOURCE, and UBSan bounds checking. Also UBSan address checking at run-time. At compile-time there is -Wstringop-overflow -fanalyzer and -Walloc-larger-than. Then also stack clash protection against stack overflow and stack protection against overflow on the stack (which is a second-line defense after bounds checking, which failed here in a very specific case to protect alloca and VLAs. This is - of course - by itself not a vulnerability.) https://godbolt.org/z/PfcWP55or alloca is clearly worse. Fixed size arrays on the stack which a worst-case bounds are also worse in most cases. std::vector<int> has some protection, e.g. ASAN finds the out of bounds access (at a high run-time cost) and one could activate the GLIBC assertions someho: https://godbolt.org/z/8zanMG5x4 But I would not call it safer and overhead is much worse. Fundamentally, VLAs are the dynamic buffer which can be protected most easily and should be *preferred*.
