From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 9305D1F62E for ; Tue, 15 Jan 2019 02:24:51 +0000 (UTC) Received: from localhost ([127.0.0.1]:58370 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gjEPJ-0007U1-JL for normalperson@yhbt.net; Mon, 14 Jan 2019 21:24:49 -0500 Received: from eggs.gnu.org ([209.51.188.92]:40342) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gjDyp-0003j9-4H for bug-gnulib@gnu.org; Mon, 14 Jan 2019 20:57:28 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gjDyo-0002gc-3X for bug-gnulib@gnu.org; Mon, 14 Jan 2019 20:57:27 -0500 Received: from mo6-p00-ob.smtp.rzone.de ([2a01:238:20a:202:5300::2]:17919) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gjDym-0002fA-8y for bug-gnulib@gnu.org; Mon, 14 Jan 2019 20:57:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1547517439; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=cUpnyxJeEluGMddMElHcSXUvLYBsxcL8zVYq2uQJbmM=; b=Nv3fGFmKX4B0p7LyEs3nXW+enRU9URKJOcM7TNxKMqvWmk92dZAbt4vsYie3F2RkAQ tOobZQjl/8hL0mFmh66Tpz77BuBbUyIC5VWlmmFn4JF6heyhc1fg4XNYLq1nbfss1Zao nGr+60jKT7eo49sCaYpas41vVRgTNRBlNna2//6TetI1vYRTt2a/FZV6vOTXYpMgWXUF RT3Ztn7+PP+nRyDHmb3jbv7l6IKc2l5QS+PXqMYuaNj50f0EwBAgn4GMuTMH3/Mf7YjU MagiuZ54Abx4NGYzTHFcVVxZrc7N68x1ulLlFhWwpEthix27Ir0SSGgYdkLuYuCCa3Iv 8WOw== X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH+AHjwLuWOGKf2y/s=" X-RZG-CLASS-ID: mo00 Received: from bruno.haible.de by smtp.strato.de (RZmta 44.9 DYNA|AUTH) with ESMTPSA id v0a34ev0F1vHqSp (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Tue, 15 Jan 2019 02:57:17 +0100 (CET) From: Bruno Haible To: bug-gnulib@gnu.org Subject: Re: VLA and alloca Date: Tue, 15 Jan 2019 02:57:14 +0100 Message-ID: <2625370.QrXcNNoFVb@omega> User-Agent: KMail/5.1.3 (Linux/4.4.0-141-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <8b1499e2-4b89-02b1-f3e0-845072a12796@draigBrady.com> References: <8b1499e2-4b89-02b1-f3e0-845072a12796@draigBrady.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a01:238:20a:202:5300::2 X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: James Youngman , Bernhard Voelker Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" Hi, P=E1draig 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 >=20 > > 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. > >=20 > > 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. >=20 > 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=3DN [1], whose purpose is that the stack "jumps" by not more than one page at once. * It also has a warning -Walloca-larger-than=3DN [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 allocati= ons 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.ht= ml