On Tue, Mar 05, 2024 at 07:01:50PM +0100, Mattias Rönnblom wrote: > On 2024-03-04 17:34, Tyler Retzlaff wrote: > >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 > > GCC documentation discourages statement expressions *of a particular > form* from being included in headers to be consumed by C++. > > They would be fine to use here, especially considering they wouldn't > be a part of the public API (i.e., only invoked from the static > inline functions in the API).
agreed, there should be no problem. > > >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.
