[dpdk-dev] [EXT] [PATCH v3] doc: announce API changes for Windows compatibility
Dmitry Kozlyuk
dmitry.kozliuk at gmail.com
Wed Jun 9 17:52:12 CEST 2021
2021-05-20 20:17 (UTC+0000), Akhil Goyal:
> >
> > 2021-05-20 18:59 (UTC+0000), Akhil Goyal:
> > > > Windows system headers define `s_addr`, `min`, and `max` macros which
> > > > break structure definitions containing fields with one of these names.
> > > > Undefining those macros would break consumer code that relies on
> > them.
> > > >
> > >
> > > From the commit message the requirement for changing the structure
> > definitions
> > > Is not clear. Please note that 'min' - 'max' are not macros. These are
> > variables of a
> > > structure which should not break any other structure/Macro in windows.
> >
> > Err, yes, that's what the commit message says.
> > Structure fields of course break nothing; they are broken by Windows
> > macros.
> > Would this make more sense?
> >
> >
> > Windows headers define `s_addr`, `min`, and `max` as macros.
> > If DPDK headers are included after Windows ones, DPDK structure
> > definitions containing fields with these names get broken.
> > If DPDK headers undefined these macros, it could break consumer
> > code
> > relying on these macros. It is proposed to rename structure fields
> > in DPDK, because Win32 headers are more widely used and harder
> > to fix.
>
> Yes it makes more sense now. But ideally it should be fixed in windows.
> This may be just one such issue, there may be many more.
> Will this also mean that nobody can define a local variable 'min'?
> Is this acceptable?
Only in public headers. There happens to be one such, rte_lru_x86.h.
> Any macro definition in a subsystem should have a prefix to denote that,
> Just like in DPDK 'RTE_' is added.
> 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.
Friendly ping to everyone Akhil cc'ed.
As far as I understand, if we want to fix it in 21.11,
deprecation notice should make it into 21.08.
More information about the dev
mailing list