Re: enabling -Werror=assign-enum for kernel

On Wed, Aug 26, 2026 at 02:50:55PM -0400, John Baldwin wrote:
J> > J> > Noted.  I can't make a judgement if it is a smart restriction by C++ or not.
J> > J> > In our case using enums as flags is common and handy and Werror=assign-enum in
J> > J> > combination with __attribute__((flag_enum)) will make this use fortified
J> > J> > against mistakes.
J> > J>
J> > J> Mostly my point is that over time we may be forced to convert away from enums to
J> > J> plain constants if more of the base system starts using C++ anyway.  At least for
J> > J> enums exposed to userspace.
J> > 
J> > But if C++ doesn't allow flag enums in principle, then they just can't go into
J> > userspace headers, no matter how we compile the kernel.  Basically we already
J> > are there, and enabling Werror=assign-enum for kernel won't change anything,
J> > will it?
J> 
J> No, it won't change anything, but over time we might find we have to convert some
J> enums to constants.  I would only do those on an as-needed basis though, I wouldn't
J> go about doing it now.  I might suggest that we should avoid adding _new_ enums
J> that are treated as flags.

I can't agree with that.  If inpcb->inp_flags and tcpcb->t_flags were flag
enums and we had Werror=assign-enum enabled, that would had saved me so much
time in the last 10 years.

I think we should use flag enums and use power of compiler to guard from human
errors associated with using #define for flags.  Of course the C++ restricts
exposing that to certain KPIs.  Those who really want to use C++ to mess with
internal kernel structures, they always have <static_cast>

-- 
Gleb Smirnoff