Re: enabling -Werror=assign-enum for kernel

> On 26. Aug 2026, at 20:59, Gleb Smirnoff <[email protected]> wrote:
> 
> 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.
Hi Gleb,

could you elaborate on what took time? Knowing this would help me
to understand the benefits of your proposal.

Best regards
Michael
> 
> 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
>