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