On Sun, Mar 03, 2024 at 07:26:36AM +0100, Mattias Rönnblom wrote: > On 2024-03-02 18:05, Stephen Hemminger wrote: > >On Sat, 2 Mar 2024 14:53:22 +0100 > >Mattias Rönnblom <mattias.ronnb...@ericsson.com> wrote: > > > >>diff --git a/lib/eal/include/rte_bitops.h b/lib/eal/include/rte_bitops.h > >>index 449565eeae..9a368724d5 100644 > >>--- a/lib/eal/include/rte_bitops.h > >>+++ b/lib/eal/include/rte_bitops.h > >>@@ -2,6 +2,7 @@ > >> * Copyright(c) 2020 Arm Limited > >> * Copyright(c) 2010-2019 Intel Corporation > >> * Copyright(c) 2023 Microsoft Corporation > >>+ * Copyright(c) 2024 Ericsson AB > >> */ > > > >Unless this is coming from another project code base, the common > >practice is not to add copyright for each contributor in later versions. > > > > Unless it's a large contribution (compared to the rest of the file)? > > I guess that's why the 916c50d commit adds the Microsoft copyright notice. > > >>+/** > >>+ * Test if a particular bit in a 32-bit word is set. > >>+ * > >>+ * This function does not give any guarantees in regards to memory > >>+ * ordering or atomicity. > >>+ * > >>+ * @param addr > >>+ * A pointer to the 32-bit word to query. > >>+ * @param nr > >>+ * The index of the bit (0-31). > >>+ * @return > >>+ * Returns true if the bit is set, and false otherwise. > >>+ */ > >>+static inline bool > >>+rte_bit_test32(const uint32_t *addr, unsigned int nr); > > > >Is it possible to reorder these inlines to avoid having > >forward declarations? > > > > Yes, but I'm not sure it's a net gain. > > A statement expression macro seems like a perfect tool for the job, > but then MSVC doesn't support statement expressions. You could also > have a macro that just generate the function body, as oppose to the > whole function.
statement expressions can be used even with MSVC when using C. but GCC documentation discourages their use for C++. since the header is consumed by C++ in addition to C it's preferrable to avoid them. > > I'll consider if I should just bite the bullet and expand all the > macros. 4x duplication. > > >Also, new functions should be marked __rte_experimental > >for a release or two. > > Yes, thanks.
