> From: Thomas Monjalon [mailto:tho...@monjalon.net] > Sent: Sunday, 18 February 2024 16.35 > > 18/02/2024 13:53, Morten Brørup: > > > From: Thomas Monjalon [mailto:tho...@monjalon.net] > > > Sent: Sunday, 18 February 2024 13.24 > > > > > > 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. > > > > This topic has previously been discussed in another context - adding > external libraries [1]. > > > > Like you do here, I generally preferred #ifdefs in the code, but the > majority preferred stubs "promoting improved code readability". > > Stubs may make sense in many places, > but here we are talking about rte_common.h > where we abstract differences between arch and compilers, > so it is the right place to be explicit with compilers support.
Very strong point. I'm convinced. Should the new rte_attribute() macro still be introduced for other uses of __attribute__(), e.g. the somewhat exotic attributes in eal/include/rte_lock_annotations.h? The not-so-exotic attributes could have new macros added, e.g. __rte_const and __rte_pure. > > > I might argue that Tyler is following that guidance here; and perhaps > the decision should be reconsidered, now that we have a real-life > example of how it affects code readability. ;-) > > > > [1]: https://inbox.dpdk.org/dev/20240109141009.497807-1- > jer...@marvell.com/ > >
