DPDK patches and discussions
 help / color / mirror / Atom feed
From: Tyler Retzlaff <roretzla@linux.microsoft.com>
To: Akhil Goyal <gakhil@marvell.com>
Cc: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>,
	"dev@dpdk.org" <dev@dpdk.org>,
	Ferruh Yigit <ferruh.yigit@intel.com>,
	Fiona Trahe <fiona.trahe@intel.com>,
	Ashish Gupta <ashishg@marvell.com>, Khoa To <khot@microsoft.com>,
	Ray Kinsella <mdr@ashroe.eu>, Neil Horman <nhorman@tuxdriver.com>,
	Thomas Monjalon <thomas@monjalon.net>,
	"bruce.richardson@intel.com" <bruce.richardson@intel.com>,
	Konstantin Ananyev <konstantin.ananyev@intel.com>,
	Jerin Jacob Kollanukkaran <jerinj@marvell.com>,
	"Zhang, Roy Fan" <roy.fan.zhang@intel.com>
Subject: Re: [dpdk-dev] [EXT] [PATCH v3] doc: announce API changes for Windows compatibility
Date: Thu, 17 Jun 2021 07:27:13 -0700	[thread overview]
Message-ID: <20210617142713.GB29777@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> (raw)
In-Reply-To: <MW2PR18MB228451B945591C14A48D5727D82A9@MW2PR18MB2284.namprd18.prod.outlook.com>

On Thu, May 20, 2021 at 08:17:54PM +0000, Akhil Goyal wrote:
> > 
> 
> Yes it makes more sense now. But ideally it should be fixed in windows.

they won't be fixed in windows.  it is extremely rare to withdraw
something from a platform headers namespace and is avoided to maintain
API compatibility no matter how horrible these macros are.

> This may be just one such issue, there may be many more.
> Will this also mean that nobody can define a local variable 'min'?

that is correct. As well as a long list of other commonly used names not
only from windows but other platform headers, standard library headers
and keywords.

> Any macro definition in a subsystem should have a prefix to denote that,
> Just like in DPDK 'RTE_' is added.

completely agree, best practice would be to avoid contaminating the
applications namespace.

> Macros with generic names should be avoided so that we do not get into
> these issues.
> 
> Adding more people for comments. I don't have a good feeling about
> this change.

there is no real choice, the platform header won't be "fixed" so it has
to be dealt with and even thinking you can avoid it by just not
including windows.h here keep in mind the consuming application will
have to anyway so it's difficult to avoid.

  parent reply	other threads:[~2021-06-17 14:27 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-03 22:51 [dpdk-dev] [PATCH] doc: announce renaming of rte_ether_hdr fields Dmitry Kozlyuk
2021-03-03 23:54 ` Stephen Hemminger
2021-03-04  7:09   ` Dmitry Kozlyuk
2021-05-20 14:28     ` Ferruh Yigit
2021-03-10 23:54 ` [dpdk-dev] [PATCH v2] doc: announce API changes for Windows compatibility Dmitry Kozlyuk
2021-03-11 16:19   ` John Alexander
2021-03-11 17:01     ` Dmitry Kozlyuk
2021-03-11 17:08       ` Tyler Retzlaff
2021-03-16 10:37   ` Thomas Monjalon
2021-05-20 18:42   ` [dpdk-dev] [PATCH v3] " Dmitry Kozlyuk
2021-05-20 18:59     ` [dpdk-dev] [EXT] " Akhil Goyal
2021-05-20 19:31       ` Dmitry Kozlyuk
2021-05-20 20:17         ` Akhil Goyal
2021-06-09 15:52           ` Dmitry Kozlyuk
2021-06-23 15:14             ` Dmitry Kozlyuk
2021-06-17 14:27           ` Tyler Retzlaff [this message]
2021-07-21 19:55     ` [dpdk-dev] " Dmitry Kozlyuk
2021-07-21 19:55       ` [dpdk-dev] [PATCH v4] " Dmitry Kozlyuk
2021-08-02 12:13         ` Thomas Monjalon
2021-08-02 12:45           ` [dpdk-dev] [EXT] " Akhil Goyal
2021-08-02 13:00             ` Dmitry Kozlyuk
2021-08-02 13:48               ` Akhil Goyal
2021-08-02 14:57                 ` Tal Shnaiderman
2021-08-02 17:46                 ` Thomas Monjalon
2021-05-20 14:24 ` [dpdk-dev] [PATCH] doc: announce renaming of rte_ether_hdr fields Ferruh Yigit
2021-05-20 15:06   ` Dmitry Kozlyuk
2021-05-20 15:27     ` Ferruh Yigit
2021-05-20 15:50       ` Dmitry Kozlyuk
2021-05-20 16:04         ` Ferruh Yigit
2021-05-20 16:16           ` Dmitry Kozlyuk
2021-05-20 16:25             ` Ferruh Yigit

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=20210617142713.GB29777@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net \
    --to=roretzla@linux.microsoft.com \
    --cc=ashishg@marvell.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=dmitry.kozliuk@gmail.com \
    --cc=ferruh.yigit@intel.com \
    --cc=fiona.trahe@intel.com \
    --cc=gakhil@marvell.com \
    --cc=jerinj@marvell.com \
    --cc=khot@microsoft.com \
    --cc=konstantin.ananyev@intel.com \
    --cc=mdr@ashroe.eu \
    --cc=nhorman@tuxdriver.com \
    --cc=roy.fan.zhang@intel.com \
    --cc=thomas@monjalon.net \
    /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).