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

[Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>]

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.