Re: enabling -Werror=assign-enum for kernel

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

Trivial: I merge FreeBSD into internal tree and there are flag collisions.
These collisions are missed by my eye and then not detected by compiler.  Easy
case if they result in immediate panic or lack of connectivity.  Worse when
system runs in general and bugs are discovered only when it is passed to the
testing cycle.

-- 
Gleb Smirnoff