From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 45134 invoked by alias); 19 Sep 2019 19:40:26 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 45126 invoked by uid 89); 19 Sep 2019 19:40:26 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=H*r:10.0.1, HX-Spam-Relays-External:!127.0.0.1!, H*RU:!127.0.0.1!, HContent-Transfer-Encoding:8bit X-HELO: mx1.riseup.net Received: from mx1.riseup.net (HELO mx1.riseup.net) (198.252.153.129) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 19 Sep 2019 19:40:25 +0000 Received: from capuchin.riseup.net (capuchin-pn.riseup.net [10.0.1.176]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id 65EB41A10B4 for ; Thu, 19 Sep 2019 12:40:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1568922023; bh=fwF6haTze+Qbg6jkaBawdycO+6NVi1rfDxDP9Qh7kBA=; h=Date:From:To:Subject:From; b=En6f+TK32OvxyepxjWWz0Bczg6SDOw5vEs13zIjyljZn+mzbcDYRfk97KdCbYlUaw 0+0SB8vonZ2o9k2TfuVHWT5FVOn3lyD54plItMoJr59vqR9eUb62lwOeAVktsTTQvB nJnmaT9FeL//9j8XVJsvlrqjsUVeuYoI0/aLERVc= X-Riseup-User-ID: 2705C0B080390677CB2F5FB3D4F84EDD4388423F10264A1DBE51F401D55F11C3 Received: from [127.0.0.1] (localhost [127.0.0.1]) by capuchin.riseup.net (Postfix) with ESMTPSA id 484171207E8 for ; Thu, 19 Sep 2019 12:40:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: Thu, 19 Sep 2019 19:40:00 -0000 From: =?UTF-8?Q?Elias_=C3=85str=C3=B6m?= To: gcc@gcc.gnu.org Subject: More relaxed -Wvla option (allowing VLA pointers) Message-ID: <904e09370dd617e23679ee02ed20d75c@riseup.net> X-SW-Source: 2019-09/txt/msg00150.txt.bz2 Hi! Some projects (most notably the linux-kernel) choose to use -Wvla to warn on usage of variable length array. The primary reason is usually that it can cause stack overflows if the programmer isn't careful, which introduces a security vulnerability. I think an overlooked advantage of VLA's is the ability to create indexable multi-dimensional arrays with run-time sizes. These arrays doesn't have to be allocated on the stack, they can also be pointers to head-allocated memory. VLA's can also be useful to document preconditions on array-sizes in function-prototypes. I would like to suggest an option to warn against creating VLA objects on the stack, but not for VLA-pointers. When that is enabled the following scenarios will not emit warnings: Scenario 1. Using decayed pointers from VLA's in function parameters int sum(int n, int a[n]); Scenario 2. Using pointers and manipulating pointers to VLA objects float (*matrix1)[n][m] = malloc(sizeof *matrix); float (*matrix2)[m] = malloc(n * sizeof *matrix); While creating a VLA object on stack would still emit a warning: int f(int n) { int a[n]; // warning for creating a VLA object on the stack } Also note that scenario 1 can occur when including header files from a library that uses VLA's in function prototypes to annotate dynamic array sizes. I personally would like to see more libraries use C99 VLA's to annotate array sizes in function prototypes, but it would be annoying if that makes them unusable with "-Wvla". I think this could either be an entirely new option, maybe called "-Wvla-stack". Or an option to use in combination with -Wvla, maybe called "-Wno-vla-pointer" which has the same behavior when used like "-Wvla -Wno-vla-pointer". Just thought this would preserve many of the advantages of VLA's for software projects hesitant to enable VLAs completely to avoid stack smashing. You may implement it if you want, but I would be glad if you would consider it. Regards, Elias Åström