Hi, Pádraig Brady wrote: > > In function 'dcpgettext_expr': > > /home/james/source/GNU/findutils/git/gnu/findutils/gl/lib/gettext.h:216: > > warning: variable length array 'msg_ctxt_id' is used > > > In other words, "gcc -Wvla" is issuing a warning for a construct we > > know is safe. However, I can't be sure I won't accidentally write > > code in the future which is not protected by something similar to > > _LIBGETTEXT_HAVE_VARIABLE_SIZE_ARRAYS. So I think that -Wvla is a > > useful warning flag. > > > > Is there a way of eliminating this false positive which doesn't force > > me to give up -Wvla? I mean, apart from giving up the use of VLAs in > > gnulib even when it's safe to use them. > > We might want to disable use of VLAs even if the compiler supports it, > for security reasons (like the Linux kernel now does)
The proposed patch looks reasonable to me. And it would be useful to add a bit of documentation, namely: Who should define GNULIB_NO_VLA, and for what reasons? There are two related issues: * GCC not only has a warning -Wvla (whose purpose is probably to avoid VLAs in order to produce code compatible with other compilers), but also -Wvla-larger-than=N [1], whose purpose is that the stack "jumps" by not more than one page at once. * It also has a warning -Walloca-larger-than=N [1], with the same purpose. Maybe we can come to a gnulib-wide policy regarding the use of alloca() and VLAs? Does glibc have such a policy? My thoughts regarding these options are mixed: * On one hand, we are regularly using machines where a process may have more than 1 million of memory pages. A policy that forbids stack allocations of more than 1 page has the effect that the stack will rarely grow beyond 200 memory pages. The resulting pressure to use heap allocations instead of stack allocations may be justified for multi-thread applications, but is not justified for single-thread applications, which could otherwise use 200000 memory pages of stack without problems. * On the other hand, there is the problem of detecting a stack that "jumps". There are mitigations in the Linux kernel [2][3], as well as in GCC: GCC has an option -fstack-clash-protection [4]. What are the widely accepted points of view on these topics? Bruno [1] https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Warning-Options.html [2] https://lwn.net/Articles/725832/ [3] https://lwn.net/Articles/727703/ [4] https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Instrumentation-Options.html
