From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 9628043E38; Wed, 10 Apr 2024 19:10:11 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5F89040648; Wed, 10 Apr 2024 19:10:11 +0200 (CEST) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id 92D9140395; Wed, 10 Apr 2024 19:10:09 +0200 (CEST) Received: by linux.microsoft.com (Postfix, from userid 1086) id B8A7120EB223; Wed, 10 Apr 2024 10:10:08 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com B8A7120EB223 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1712769008; bh=m6SdOmbLbLsZU5lpR+D/ywTbXMsBeRyKEyFKCntutUA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=e4610B9dKBexu7E/QFlG59/mjCMnJo1S2dWDJAVhqPQ6Qt1oyOocYXrfXutU6pEU3 n6VvWgn26QaizhLEVT7t5vDYWoEeky9xndRuMHOLBldxWmniS1I/+qard7tFu01jhI owumd036KXnPAionu3DJNgktjoPOxHDBxnx9609o= Date: Wed, 10 Apr 2024 10:10:08 -0700 From: Tyler Retzlaff To: Mattias =?iso-8859-1?Q?R=F6nnblom?= Cc: Stephen Hemminger , techboard@dpdk.org, Morten =?iso-8859-1?Q?Br=F8rup?= , dev@dpdk.org, Bruce Richardson , Thomas Monjalon Subject: Re: [PATCH 0/4] RFC samples converting VLA to alloca Message-ID: <20240410171008.GC29636@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <20231107193220.GA15232@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <1712250913-1977-1-git-send-email-roretzla@linux.microsoft.com> <98CBD80474FA8B44BF855DF32C47DC35E9F379@smartserver.smartshare.dk> <20240407100306.36c9688f@hermes.local> <20240408152703.GA25804@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Wed, Apr 10, 2024 at 09:27:10AM +0200, Mattias Rönnblom wrote: > On 2024-04-08 17:27, Tyler Retzlaff wrote: > >For next technboard meeting. > > > >On Sun, Apr 07, 2024 at 10:03:06AM -0700, Stephen Hemminger wrote: > >>On Sun, 7 Apr 2024 13:07:06 +0200 > >>Morten Brørup wrote: > >> > >>>>From: Mattias Rönnblom [mailto:hofors@lysator.liu.se] > >>>>Sent: Sunday, 7 April 2024 11.32 > >>>> > >>>>On 2024-04-04 19:15, Tyler Retzlaff wrote: > >>>>>This series is not intended for merge. It insteat provides examples > >>>>of > >>>>>converting use of VLAs to alloca() would look like. > >>>>> > >>>>>what's the advantages of VLA over alloca()? > >>>>> > >>>>>* sizeof(array) works as expected. > >>>>> > >>>>>* multi-dimensional arrays are still arrays instead of pointers to > >>>>> dynamically allocated space. this means multiple subscript syntax > >>>>> works (unlike on a pointer) and calculation of addresses into > >>>>allocated > >>>>> space in ascending order is performed by the compiler instead of > >>>>manually. > >>>> > >>>>alloca() is a pretty obscure mechanism, and also not a part of the C > >>>>standard. VLAs are C99, and well-known and understood, and very > >>>>efficient. > >>> > >>>The RFC fails to mention why we need to replace VLAs with something else: > >>> > >>>VLAs are C99, but not C++; VLAs were made optional in C11. > >>> > >>>MSVC doesn't support VLAs, and is not going to: > >>>https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc/#variable-length-arrays > >>> > >>> > >>>I dislike alloca() too, and the notes section in the alloca(3) man page even discourages the use of alloca(): > >>>https://man7.org/linux/man-pages/man3/alloca.3.html > >>> > >>>But I guess alloca() is the simplest replacement for VLAs. > >>>This RFC patch series opens the discussion for alternatives in different use cases. > >>> > >> > >>The other issue with VLA's is that if the number is something that can be externally > >>input, then it can be a source of stack overflow bugs. That is why the Linux kernel > >>has stopped using them; for security reasons. DPDK has much less of a security > >>trust domain. Mostly need to make sure that no data from network is being > >>used to compute VLA size. > >> > > > >Looks like we need to discuss this at the next techboard meeting. > > > >* MSVC doesn't support C11 optional VLAs (and never will). > > This is due to dogmatism, or what? Surely, a lot of Open Source > projects written for C99 will use VLAs. well the statement from the MSVC team was "VLAs provide attack vectors comparable to those of the infamous gets() — deprecated and destined to removal — for opportunities of “shifting the stack” and other exploits. For these reasons we intend not to support VLAs as an optional feature in C11" i'm only communicating that they will neve be supported not debating the reasons why. it's simply a statement in fact. > > >* alloca() is an alternative that is available on all platforms/toolchain > > combinations. > > alloca() is a poor alternative. The use of alloca() should be > restricted to situations where statically sized arrays can't do the > job. agree comletely.