Re: enabling -Werror=assign-enum for kernel

> On 27. Aug 2026, at 17:35, Gleb Smirnoff <glebius@FreeBSD.org> wrote:
> 
> 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.
Which ones? I am only aware of missing values in a switch statement.

Best regards
Michael
> 
> -- 
> Gleb Smirnoff