From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
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 <dev@dpdk.org>; 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 <bruce.richardson@intel.com>
To: Morten =?iso-8859-1?Q?Br=F8rup?= <mb@smartsharesystems.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>, dev@dpdk.org
Subject: Re: [RFC 0/2] Eliminate zero length arrays in DPDK
Message-ID: <YgzNeYi73AbVih45@bricha3-MOBL.ger.corp.intel.com>
References: <20220215230058.64760-1-stephen@networkplumber.org>
 <YgzEznz3PGAAPjS+@bricha3-MOBL.ger.corp.intel.com>
 <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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=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