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 E434C1BB4F for ; Thu, 20 Dec 2018 12:03:13 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 6689421D07; Thu, 20 Dec 2018 06:03:13 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Thu, 20 Dec 2018 06:03:13 -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=NCE3uxDEB1PWafFzmNyKnQ4mMeXcH+eizI+61vuqcWE=; b=BplcuY9p3uXY kuKRLmlCTtOJywociBQri1UzlFa9JZ39Abv3J56Dq975277Mi/vOIHGjvTdJs6UP JF0StNaeU/VDHISZPOL6wBMcoK9yUV2Njj9j76IMSRnyKb7eN/UaqVZVLDARJ//o 8MMKGhL/+bNr+O/X1sf3hko3XGUee+E= 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=NCE3uxDEB1PWafFzmNyKnQ4mMeXcH+eizI+61vuqc WE=; b=gwx4I32Ntx7svoMWbVpX5TTIEp/gIIwlLX6kME0K7a3izxzCMdY+BDXXR n9ZE37jh/zH7eBVjE8Y6qBdNa1x/yihtETlM+FUe+qK+qXhzWNf8OrLnl/BwshBT V4XhlM0rHuty2aFL4j5GBnQOPu9U+EL9wcgJsYmNCKC3JuryeJhsTJiMwsGX4nYC AiRnLClfZjbjtm9sc3PfsZdrq1m9KwcDEnbpZeDckYevPEq0zSbHxVQIDeWMqBbH BqsUj8xShiEegYOGQazuRAf6MwYoFpbsozCrmASEHfRaCA09rqmmgW/S/1Wj5Id0 QLjQWjcOu+dLq5BLbaETkkyXUeg/w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtkedrudejfedgvdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvffufffkjg hfggfgtgesthhqredttddtjeenucfhrhhomhepvfhhohhmrghsucfoohhnjhgrlhhonhcu oehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkphepjeejrddufeegrddvtd efrddukeegnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd 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 78689102DD; Thu, 20 Dec 2018 06:03:07 -0500 (EST) From: Thomas Monjalon To: Mattias =?ISO-8859-1?Q?R=F6nnblom?= , Jason Messer , harini.ramakrishnan@microsoft.com Cc: dev@dpdk.org, Jeff Shaw , stephen@networkplumber.org Date: Thu, 20 Dec 2018 12:03:06 +0100 Message-ID: <2132371.0rAaFhJRHa@xps> In-Reply-To: References: <20181214163827.9403-1-jeffrey.b.shaw@intel.com> <27594774.hr4jPcleJC@xps> 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: Thu, 20 Dec 2018 11:03:14 -0000 20/12/2018 11:53, Mattias R=C3=B6nnblom: > On 2018-12-19 22:45, Thomas Monjalon wrote: > > 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 j= ust > >>>> achieves the same thing in an uglier, less portable way than VLAs. > >>> > >>> I agree that it is much less elegant than a VLA. This is in preparati= on > >>> for DPDK on Windows, which using the Microsoft Visual C++ (MSVC) comp= iler. > >>> MSVC does not support variable length arrays. It does, however, suppo= rt > >>> alloca(), as does GCC/ICC. > >>> > >>> 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 n= ot > >>> 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. > >> > >> If Microsoft's C compiler doesn't support C99, some 20 years after its > >> release, maybe it's time to find a new compiler, instead of messing up > >> the DPDK code in a ~100 instances. > >=20 > > If think there is no reasonnable compiler for Windows. > > Yes I know, it's crazy. > >=20 > With's wrong with the Windows version of Clang? I agree it should be the preferred compiler for DPDK on Windows. But Microsoft told there are some issues working with clang. Jason, Harini, please, could you elaborate?