From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 73F071B296 for ; Wed, 19 Dec 2018 22:46:01 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 1C0B022141; Wed, 19 Dec 2018 16:46:01 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Wed, 19 Dec 2018 16:46:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=v8lowPK3ygnbFLUeMcqUUCPTGecp/b/wQQd2uB98NuU=; b=qulRvlSRq/dP Jv0PHEMHrO6s7s7/2pHJzQ2kDCxWK5xqQBT9B8WoRwhL8WBpAzmPom6lMK639o17 /3dMQrLl28URl5VY2Bfl3YUSeqoL2HPDdM1ZmUxNiqTHBizQuBsB0mcuhKqWVLYH ScBSQHYPsc0APqE5kTCC4lO26XyyQGY= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=v8lowPK3ygnbFLUeMcqUUCPTGecp/b/wQQd2uB98N uU=; b=qsGo1S0nCcc91b38/nnMPnU0g9H9W2Gak3f0QMZgPrXeI3X0cXJ3BS1ah hcxh/V+3VUPDHswB+6T0o/9dURdfslpX3l7QbC7nPElhOhHwnfAE4EjHrnjVzQbA rfz+GO6g19cKFjRD7JyMRDzMRHAHrQEiogtQrDi0Ip2WhEchi4n+Jj3PWnH4pJ9n VJgKSyM4QqtNbD28XXVxDhnJXfxMxKaj4P28OoJlULEInXhsoMSLmjlP4tzrd3px AeWVE3PVPWodWoTqqO83RTsXc4iTALreFDAo2lPo9FnB18RLE7E10G7FRetyCkvv bs8jzHSzVFKZiBR3S8Mi5w9IijpEw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtkedrudejtddgudehgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecu fedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufffkf gjfhgggfgtsehtqhertddttdejnecuhfhrohhmpefvhhhomhgrshcuofhonhhjrghlohhn uceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukfhppeejjedrudefgedrvd dtfedrudekgeenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgr lhhonhdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id AF5C8E4445; Wed, 19 Dec 2018 16:45:59 -0500 (EST) From: Thomas Monjalon To: Mattias =?ISO-8859-1?Q?R=F6nnblom?= , Jason Messer Cc: dev@dpdk.org, Jeff Shaw , stephen@networkplumber.org, harini.ramakrishnan@microsoft.com Date: Wed, 19 Dec 2018 22:45:58 +0100 Message-ID: <27594774.hr4jPcleJC@xps> In-Reply-To: <3a573b56-6ea0-812c-4641-830fbd3c59cc@ericsson.com> References: <20181214163827.9403-1-jeffrey.b.shaw@intel.com> <20181214190713.GB9964@ae13-28.jf.intel.com> <3a573b56-6ea0-812c-4641-830fbd3c59cc@ericsson.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH] eal: remove variable length array X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2018 21:46:01 -0000 14/12/2018 21:28, Mattias R=C3=B6nnblom: > On 2018-12-14 20:07, Jeff Shaw wrote: > >>> The code prior to this commit produced the following warning when > >>> compiled with "-Wvla -std=3Dc90". > >>> > >>> warning: ISO C90 forbids variable length array =E2=80=98array=E2= =80=99 [-Wvla] > >>> > >>> This commit removes the variable length array from the PMD debug > >>> trace function by allocating memory dynamically on the stack using > >>> alloca(). > >> > >> Is alloca() even included in *any* C standard? As far as I see, it just > >> achieves the same thing in an uglier, less portable way than VLAs. > >=20 > > I agree that it is much less elegant than a VLA. This is in preparation > > for DPDK on Windows, which using the Microsoft Visual C++ (MSVC) compil= er. > > MSVC does not support variable length arrays. It does, however, support > > alloca(), as does GCC/ICC. > >=20 > > For this particular instance, the point is moot, since the function is > > not used anywhere and can just as easily be removed. Though it does not > > address the issue for the ~100 other instances where VLAs are used. We > > will be submitting patches for those as more common files are ported to > > Windows. >=20 > If Microsoft's C compiler doesn't support C99, some 20 years after its=20 > release, maybe it's time to find a new compiler, instead of messing up=20 > the DPDK code in a ~100 instances. If think there is no reasonnable compiler for Windows. Yes I know, it's crazy. Microsoft, should we wait 10 more years to have C99 supported in MSVC?