Re: enabling -Werror=assign-enum for kernel

> On 26. Aug 2026, at 21:17, Gleb Smirnoff <glebius@FreeBSD.org> wrote:
> 
> 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.
OK, I do understand this problem. But how does using an enum solve this.
As far as I know, duplicate entries in an enum are allowed.

enum test {
	one = 1,
	two,
	eins = 1
};

int
main(void) {
	return (0);
}

compiles fine for me.
How do you use enums to detect duplicate entries (collisions)?

Best regards
Michael

> 
> -- 
> Gleb Smirnoff