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 5C93BA034D; Wed, 16 Feb 2022 11:15:27 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EC7E6410FF; Wed, 16 Feb 2022 11:15:26 +0100 (CET) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by mails.dpdk.org (Postfix) with ESMTP id C1831410FB for ; Wed, 16 Feb 2022 11:15:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1645006525; x=1676542525; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=R2/iQF/FaLeRuBjoWn6kLggQl/joAk16QjjWt5ytOQE=; b=cW7NYuCs0BySGn0rajypXzGS9ApD9nwt/KHOPSuXKIfvDrzKVEn9Jqvg StNmvxG8ag1CmE69jaaQavv0XwLUS3s5Sbd7RnS9tIikDicN6Qwr5VWGl DrKxl09yEqSkzevJ179qZJEzerbmWuSpHCdN2TQ+0bIRnp8jm4uikPHNs LjymH3NSrLOC09CFxSruXf8gqOR2BhD973jb6xX000UHCD5lI4Abv2XhO +VAz41mTaC3+/LyqkYNF9vQJvHdRlK8i53fEbFEUHD7KmV/B4+LWFM7uo RfjYuNPa4t4tk+UGJ++50SWNXlMORicu5FOLOnRAngQsJ9wy6KWll2jVk A==; X-IronPort-AV: E=McAfee;i="6200,9189,10259"; a="313845508" X-IronPort-AV: E=Sophos;i="5.88,373,1635231600"; d="scan'208";a="313845508" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Feb 2022 02:10:06 -0800 X-IronPort-AV: E=Sophos;i="5.88,373,1635231600"; d="scan'208";a="704243347" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.21.192]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 16 Feb 2022 02:10:04 -0800 Date: Wed, 16 Feb 2022 10:10:01 +0000 From: Bruce Richardson To: Morten =?iso-8859-1?Q?Br=F8rup?= Cc: Stephen Hemminger , dev@dpdk.org Subject: Re: [RFC 0/2] Eliminate zero length arrays in DPDK Message-ID: References: <20220215230058.64760-1-stephen@networkplumber.org> <98CBD80474FA8B44BF855DF32C47DC35D86EB0@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D86EB0@smartserver.smartshare.dk> 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, Feb 16, 2022 at 11:05:09AM +0100, Morten Brørup wrote: > > From: Bruce Richardson [mailto:bruce.richardson@intel.com] > > Sent: Wednesday, 16 February 2022 10.33 > > > > On Tue, Feb 15, 2022 at 03:00:56PM -0800, Stephen Hemminger wrote: > > > Yet another case of applying Linux kernel best practices > > > to DPDK. Flexible arrays are supported by Clang, GCC and > > > Microsoft compilers (part of C99). > > > > > Do we need to start explicitly stating that DPDK uses C99 features, and > > adding -std=c99 to our build flags? Are we also requiring that > > applications > > are compiled with c99 features to use this (I would hope that they are, > > but > > I'm not sure we can mandate it). > > No to -std=c99. It's >= C99 for applications; we should not prevent them from using a newer C standard. Yes. For build flags, I was referring only to having it in the cflags for the build of DPDK itself, not for apps. We definitely need to minimise the build flags we expose to apps. > > Adding a note about the C standard version to the DPDK requirements > documentation would be very nice. It only mentions a certain compiler > version required. But I think that documenting the detailed build and > runtime requirements (and why they are that way) is another task. > Sure, we should do that. I am just wanting to be sure that if we specify a minimum of C99, we won't get complaints back from those with legacy codebasees which only support C89/C90. I am therefore wondering if we need to have our public headers C90-compliant? /Bruce