Re: [dpdk-dev] [EXT] [PATCH v3] doc: announce API changes for Windows compatibility

[Akhil Goyal <gakhil@marvell.com>]

> 
> 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?

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.