> On 26. Aug 2026, at 21:17, Gleb Smirnoff <[email protected]> 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
