|SUCCESS| [v2] eal: silence -Wconstant-logical-operand in RTE_IS_POWER_OF_2

[dpdklab at iol.unh.edu]

Test-Label: ai-code-review
Test-Status: SUCCESS
https://dpdk.org/patch/164139

_AI Code Review_

=== Patch Review: series.patch (via Claude) ===
Review date: 2026-05-19

Commit: <sha unavailable from patch file>
Author: Stephen Hemminger <stephen at networkplumber.org>
Subject: [PATCH v2] eal: silence -Wconstant-logical-operand in RTE_IS_POWER_OF_2

This patch modifies the RTE_IS_POWER_OF_2 macro to make both operands
of the logical AND operator explicit comparisons, avoiding compiler
warnings about non-boolean constants in logical operations.

> diff --git a/lib/eal/include/rte_bitops.h b/lib/eal/include/rte_bitops.h
> index aa6ac73abb..b170447714 100644
> --- a/lib/eal/include/rte_bitops.h
> +++ b/lib/eal/include/rte_bitops.h
> @@ -1299,7 +1299,7 @@ rte_fls_u64(uint64_t x)
>  /**
>   * Macro to return 1 if n is a power of 2, 0 otherwise
>   */
> -#define RTE_IS_POWER_OF_2(n) ((n) && !(((n) - 1) & (n)))
> +#define RTE_IS_POWER_OF_2(n) ((n) != 0 && (((n) - 1) & (n)) == 0)

The comment says the macro returns 1 or 0, but does the explicit
comparison ((n) != 0 && ...) still return exactly 1 or 0 in all C
contexts? The logical AND operator guarantees 0 or 1 result, so this
looks correct.

Does multiple evaluation of 'n' remain safe for all existing callers?
The commit message mentions this has always been the case, but it's
worth verifying no new issues arise. For example, if someone passes
'n++' as the argument, the macro would evaluate 'n++' three times,
leading to undefined behavior.

Should the macro documentation be updated to explicitly warn against
passing expressions with side effects?