static_assert, sfc, and clang issues

[Stephen Hemminger]

Ran into a corner case issue, so sending to mailing list for wider discussion.

One improvement to DPDK code base planned is getting rid of variable length arrays.
VLA's can cause bugs and are not supported by the Windows compiler.
Gcc and Clang have a flag to warn on use of VLA's (-Wvla).

In DPDK one use of VLA's is in the RTE_BUILD_BUG_ON macro.
The best path is to replace the undefined array access with a better
static_assert() which is builtin to compilers.

Using static_assert() is relatively easy, there are a few places where
it does detect use of non-constant expressions in existing code but these
are fixable.

But there is one case where use static_assert() runs into a Clang bug
which is not fixed in distros: 

https://github.com/llvm/llvm-project/issues/55821

The code in question is in the sfc driver which for better or worse
has lots of assertions. The problem is that clang (except in unreleased trunk)
can not handle static_assert in a switch leg.

		switch (actions->type) {
		case RTE_FLOW_ACTION_TYPE_VOID:
			SFC_BUILD_SET_OVERFLOW(RTE_FLOW_ACTION_TYPE_VOID,
					       actions_set);
			break;

../drivers/net/sfc/sfc_flow.c:1635:4: error: expected expression
                        SFC_BUILD_SET_OVERFLOW(RTE_FLOW_ACTION_TYPE_VOID,
                        ^
../drivers/net/sfc/sfc_flow.h:36:2: note: expanded from macro 'SFC_BUILD_SET_OVERFLOW'
        RTE_BUILD_BUG_ON((_action) >= sizeof(_set) * CHAR_BIT)
        ^


There are some workarounds:
	0. Ignore it, works on Gcc, and Clang fix is pending.
	1. Remove many of these RTE_BUILD_BUG_ON's. They are really not that helpful.
	2. Add additional { } to these switch cases so they become basic blocks
	   which works around the bug.
        3. Move the assertions out of the switch

My preference is #2 but open to other options.