On Fri, 7 Feb 2025 at 17:38, Jakub Kicinski <kuba@xxxxxxxxxx> wrote:
>
> ../include/linux/vmstat.h:504:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion]
Ok.
So my gut feel is that this warning is simply bogus. We have
situations where we very intentionally use enumerations instead of a
list of #define constants.
That NR_VM_ZONE_STAT_ITEMS case really *does* look like it's a great
example of how code that doesn't care about the actual numbers, and
just wants the compiler to generate a sequence for us is supposed to
look.
Because sometimes we do enums just because it's a nice way to get
automatically incrementing values when we don't care exactly what the
values are.
And sometimes we do it for actual namespace reasons - see for example
commit 1a251f52cfdc ("minmax: make generic MIN() and MAX() macros
available everywhere") where in order to avoid clashes with the
"MIN()" macro, I made a couple of drivers that had a 'MIN' value (much
too generic a name, but it was what it was) use an enum instead.
See
git show 1a251f52cfdc drivers/hwmon/adt7475.c
for details.
Now, at least in that case I don't think there was any arithmetic with
those values, so clang-19 wouldn't complain about it either, but I
mention that commit as a case of "it's actually very valid to use an
enum for actual real honest-to-goodness integer value enumeration".
Which really makes me feel like the new clang warning is seriously misguided.
In sparse I actually wanted to have integer types that don't silently
cast to other integer types. So sparse knows the concept of "bitwise"
and "nocast" attributes. The "nocast" thing doesn't work well in
practice, but "bitwise" was a huge success and is how a lot of our
endianness problems were solved.
So the *concept* of an enum - or any other integer type - that "stays
in the type" is good, but I think it's a major mistake to think they
have to do so without any sane escape, and to only limit it to enums.
That said, we may not have *many* of those enum cases in the kernel
(and we do tend to have a history of using long series of '#define'
sequences to do these constants), so maybe the warning is acceptable
if it's a case of "this is literally the *only* one in the kernel".
But not having clang-19, I can't see if this is a case of "this is so
rare that let's just avoid it", or "this is the case that causes the
most noise for every file build, but there are lots of other cases of
this".
Linus
