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 EAE41A034C; Thu, 24 Feb 2022 22:51:35 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6FCD64113D; Thu, 24 Feb 2022 22:51:35 +0100 (CET) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id F3CBF40141 for ; Thu, 24 Feb 2022 22:51:33 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [RFC 0/2] Eliminate zero length arrays in DPDK Date: Thu, 24 Feb 2022 22:51:31 +0100 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D86EF2@smartserver.smartshare.dk> In-Reply-To: <20220217074139.GA1815@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RFC 0/2] Eliminate zero length arrays in DPDK Thread-Index: Adgj0dGwsGFqeRMCRL+TjFDx6CZojQF9Rmrw References: <20220215230058.64760-1-stephen@networkplumber.org> <98CBD80474FA8B44BF855DF32C47DC35D86EB0@smartserver.smartshare.dk> <20220217074139.GA1815@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Tyler Retzlaff" , "Bruce Richardson" Cc: "Stephen Hemminger" , 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 > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com] > Sent: Thursday, 17 February 2022 08.42 >=20 > 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=F8rup 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=3Dc99 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=3Dc99. It's >=3D 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? >=20 > 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. >=20 > i would advocate for C99 however before setting that in stone it is > fair > to ask if there are any consumers using < C99. >=20 > 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. >=20 > ty Just read that the Linux kernel is moving towards C11, or at minimum = C99, for version 5.18: https://lwn.net/SubscriberLink/885941/01fdc39df2ecc25f/ Let's be bold and push for the same for DPDK! :-) -Morten