20/02/2024 19:06, Tyler Retzlaff: > On Sun, Feb 18, 2024 at 04:31:50PM +0100, Thomas Monjalon wrote: > > 18/02/2024 15:51, Mattias Rönnblom: > > > On 2024-02-18 13:24, Thomas Monjalon wrote: > > > > 15/02/2024 23:20, Tyler Retzlaff: > > > >> Provide a new macro __rte_attribute(a) that when directly used > > > >> compiles to empty for MSVC and to __attribute__(a) when using GCC/LLVM. > > > >> > > > >> Replace direct use of __attribute__ in __rte_xxx macros where there is > > > >> existing empty expansion of the macro for MSVC allowing removal of > > > >> repeated #ifdef RTE_TOOLCHAIN_MSVC per macro to expand empty. > > > > > > > > I'm not sure it makes sense. > > > > I prefer seeing clearly what is empty with MSVC. > > > > > > Anything __rte_attribute() is empty on MSVC. You could rename it > > > __rte_attribute_ignored_by_msvc() for clarity. > > > > Yes it would bring more clarity. > > But I still prefer #ifdef which may work with more compilers. > > > > > One could note that on the ignore list are things like "may_alias" and > > > "packed", so whatever comes out of a MSVC build should not be expected > > > to actually work. > > > > > > Unless I'm missing something, for all the attributes that will have > > > MSVC-propriety equivalent, the usage pattern would have to change, since > > > the syntax is different in incompatible ways. > > > > > > Wouldn't it be better to ask the MSVC team to add support GCC > > > attributes? ICC and LLVM managed, so why not Microsoft. Then you would > > > solve this issue for all Open Source projects, not only DPDK. > > > > We can expect MSVC to improve. > > That's another reason why I prefer to keep #ifdef to keep track easily. > > MSVC is committed to provide functionality where something simply cannot > be done at all with their toolset and standard C.
That makes sense. > They will not make changes to their toolset for functionality they already > have. So you mean there is already a way to insert zero-size markers in a struct?
