Re: enabling -Werror=assign-enum for kernel

On Wed, Aug 26, 2026 at 09:39:30PM +0200, Michael Tuexen wrote:
M> > M> > J> > J> > Noted.  I can't make a judgement if it is a smart restriction by C++ or not.
M> > M> > J> > J> > In our case using enums as flags is common and handy and Werror=assign-enum in
M> > M> > J> > J> > combination with __attribute__((flag_enum)) will make this use fortified
M> > M> > J> > J> > against mistakes.
M> > M> > J> > J>
M> > M> > J> > J> Mostly my point is that over time we may be forced to convert away from enums to
M> > M> > J> > J> plain constants if more of the base system starts using C++ anyway.  At least for
M> > M> > J> > J> enums exposed to userspace.
M> > M> > J> > 
M> > M> > J> > But if C++ doesn't allow flag enums in principle, then they just can't go into
M> > M> > J> > userspace headers, no matter how we compile the kernel.  Basically we already
M> > M> > J> > are there, and enabling Werror=assign-enum for kernel won't change anything,
M> > M> > J> > will it?
M> > M> > J> 
M> > M> > J> No, it won't change anything, but over time we might find we have to convert some
M> > M> > J> enums to constants.  I would only do those on an as-needed basis though, I wouldn't
M> > M> > J> go about doing it now.  I might suggest that we should avoid adding _new_ enums
M> > M> > J> that are treated as flags.
M> > M> > 
M> > M> > I can't agree with that.  If inpcb->inp_flags and tcpcb->t_flags were flag
M> > M> > enums and we had Werror=assign-enum enabled, that would had saved me so much
M> > M> > time in the last 10 years.
M> > M> Hi Gleb,
M> > M> 
M> > M> could you elaborate on what took time? Knowing this would help me
M> > M> to understand the benefits of your proposal.
M> > 
M> > Trivial: I merge FreeBSD into internal tree and there are flag collisions.
M> > These collisions are missed by my eye and then not detected by compiler.  Easy
M> > case if they result in immediate panic or lack of connectivity.  Worse when
M> > system runs in general and bugs are discovered only when it is passed to the
M> > testing cycle.
M> OK, I do understand this problem. But how does using an enum solve this.
M> As far as I know, duplicate entries in an enum are allowed.
M> 
M> enum test {
M> 	one = 1,
M> 	two,
M> 	eins = 1
M> };
M> 
M> int
M> main(void) {
M> 	return (0);
M> }
M> 
M> compiles fine for me.
M> How do you use enums to detect duplicate entries (collisions)?

Yes, you are right.  The mistake I described above won't be catched by this
Werror.  Other enum usage errors can be caught though.

-- 
Gleb Smirnoff