From: Bruce Richardson <bruce.richardson@intel.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: dev@dpdk.org, Vladimir Medvedkin <vladimir.medvedkin@intel.com>,
John McNamara <john.mcnamara@intel.com>,
Marko Kovacevic <marko.kovacevic@intel.com>,
Matan Azrad <matan@mellanox.com>,
Shahaf Shuler <shahafs@mellanox.com>,
Viacheslav Ovsiienko <viacheslavo@mellanox.com>,
Gagandeep Singh <g.singh@nxp.com>,
Hemant Agrawal <hemant.agrawal@nxp.com>,
Sachin Saxena <sachin.saxena@nxp.com>,
Harini Ramakrishnan <harini.ramakrishnan@microsoft.com>,
Omar Cardona <ocardona@microsoft.com>,
Pallavi Kadam <pallavi.kadam@intel.com>,
Ranjit Menon <ranjit.menon@intel.com>
Subject: Re: [dpdk-dev] [PATCH] devtools: forbid variable declaration inside for
Date: Mon, 23 Mar 2020 13:59:19 +0000 [thread overview]
Message-ID: <20200323135919.GA1517@bricha3-MOBL.ger.corp.intel.com> (raw)
In-Reply-To: <20200217222654.2218926-1-thomas@monjalon.net>
On Mon, Feb 17, 2020 at 11:26:54PM +0100, Thomas Monjalon wrote:
> Some compilers raise an error when declaring a variable
> in the middle of a function. This is a C99 allowance.
> Even if DPDK switches globally to C99 or C11 standard,
> the coding rules are for declarations at the beginning
> of a block:
> http://doc.dpdk.org/guides/contributing/coding_style.html#local-variables
>
> This coding style is enforced by adding a check of
> the common patterns like "for (int i;"
>
Could we, or should we, not also revisit the coding standards for this.
Those standards are quite old now, and could do with being updated to take
account of things like the newer C standards. Obviously for consistency
reasons any changes should not be major, but I don't think we should view
the guidelines as set in stone either.
For this particular issue, I think generally having all declarations at the
beginning of a block is the right thing to do, however, I would support
relaxing this rule in a couple of scenarios, specifically:
* declaring a variable like i in a for loop, i.e. the case above
* using const on a variable declaration, marking it as const at first
assignment [because I take the view that increased use of const is almost
always a good thing]
Regards,
/Bruce
next prev parent reply other threads:[~2020-03-23 13:59 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-17 22:26 Thomas Monjalon
2020-03-23 13:40 ` David Marchand
2020-03-23 13:47 ` Thomas Monjalon
2020-03-23 13:59 ` Bruce Richardson [this message]
2020-03-23 16:12 ` Thomas Monjalon
2020-05-24 17:30 ` [dpdk-dev] [PATCH v2] " Thomas Monjalon
2020-05-24 18:30 ` Stephen Hemminger
2020-05-28 12:30 ` David Marchand
2020-07-03 9:08 ` David Marchand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200323135919.GA1517@bricha3-MOBL.ger.corp.intel.com \
--to=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=g.singh@nxp.com \
--cc=harini.ramakrishnan@microsoft.com \
--cc=hemant.agrawal@nxp.com \
--cc=john.mcnamara@intel.com \
--cc=marko.kovacevic@intel.com \
--cc=matan@mellanox.com \
--cc=ocardona@microsoft.com \
--cc=pallavi.kadam@intel.com \
--cc=ranjit.menon@intel.com \
--cc=sachin.saxena@nxp.com \
--cc=shahafs@mellanox.com \
--cc=thomas@monjalon.net \
--cc=viacheslavo@mellanox.com \
--cc=vladimir.medvedkin@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).