Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753839AbdCIIBm (ORCPT ); Thu, 9 Mar 2017 03:01:42 -0500 Received: from mail-oi0-f42.google.com ([209.85.218.42]:33655 "EHLO mail-oi0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753747AbdCIIBJ (ORCPT ); Thu, 9 Mar 2017 03:01:09 -0500 MIME-Version: 1.0 In-Reply-To: References: <20170305211254.GA3220@khazad-dum.debian.net> From: Tomas Winkler Date: Thu, 9 Mar 2017 09:54:54 +0200 Message-ID: Subject: Re: Arrays of variable length To: =?UTF-8?B?TcOlbnMgUnVsbGfDpXJk?= Cc: Henrique de Moraes Holschuh , "linux-kernel@vger.kernel.org" , linux-sparse@vger.kernel.org, Herbert Xu , Al Viro Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id v2981jEH010993 Content-Length: 1602 Lines: 39 On Mon, Mar 6, 2017 at 2:31 AM, Måns Rullgård wrote: > Henrique de Moraes Holschuh writes: > >> On Sun, 05 Mar 2017, Måns Rullgård wrote: >>> Tomas Winkler writes: >>> > Sparse complains for arrays declared with variable length >>> > >>> > 'warning: Variable length array is used' >>> > >>> > Prior to c99 this was not allowed but lgcc (c99) doesn't have problem >>> > with that https://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html. >>> > And also Linux kernel compilation with W=1 doesn't complain. >>> > >>> > Since sparse is used extensively would like to ask what is the correct >>> > usage of arrays of variable length >>> > within Linux Kernel. >>> >>> Variable-length arrays are a very bad idea. Don't use them, ever. >>> If the size has a sane upper bound, just use that value statically. >>> Otherwise, you have a stack overflow waiting to happen and should be >>> using some kind of dynamic allocation instead. >>> >>> Furthermore, use of VLAs generally results in less efficient code. For >>> instance, it forces gcc to waste a register for the frame pointer, and >>> it often prevents inlining. >> >> Well, if we're going to forbid VLAs in the kernel, IMHO the kernel build >> system should call gcc with -Werror=vla to get that point across early, >> and flush out any offenders. > > If it were up to me, that's exactly what I'd do. > Some parts of the kernel depends on VLA such as ___ON_STACK macros in include/crypto/hash.h It's actually pretty neat implementation, maybe it's too harsh to disable VLA completely. Tomas