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 6C129A0032; Thu, 17 Feb 2022 08:41:43 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 431304114B; Thu, 17 Feb 2022 08:41:41 +0100 (CET) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id 074CF4068B for ; Thu, 17 Feb 2022 08:41:40 +0100 (CET) Received: by linux.microsoft.com (Postfix, from userid 1086) id 5924820B9D30; Wed, 16 Feb 2022 23:41:39 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 5924820B9D30 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1645083699; bh=jJkVr5zEeMu2qRE+UO8Ynp0j86xsaqtMnUKVOd6U1bw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=n3XUnRnlCR5UC3PEzjvCH/KCUYvuRqLVAeypLXz4ya9rKWEUH17Nq7fLrhj45THG6 RLZdAzWSgLST87ukMVQtb8gXPMe8sV+JSHyg+E8D3fZBfcsIREiQuU7tjYmalATE5G EM215Va9/+Beu/8dhECtEh2Qa+aaBzfTYSnhhi+E= Date: Wed, 16 Feb 2022 23:41:39 -0800 From: Tyler Retzlaff To: Bruce Richardson Cc: Morten =?iso-8859-1?Q?Br=F8rup?= , Stephen Hemminger , dev@dpdk.org Subject: Re: [RFC 0/2] Eliminate zero length arrays in DPDK Message-ID: <20220217074139.GA1815@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> 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: 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, Feb 16, 2022 at 10:10:01AM +0000, Bruce Richardson wrote: > 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? this seems to be the real question. what "minimum" C standard should be documented as required to consume dpdk. we can obviously use any standard we wish to build/provide binaries. similarly we ought to document a minimum C++ standard for consumption. i would advocate for C99 however before setting that in stone it is fair to ask if there are any consumers using < C99. we may also want to consider that the minimum required may differ depending on the platform/port. though most differences in public interface i would hope could be trivially abstracted though. ty