On Wed, Aug 26, 2026 at 02:50:55PM -0400, John Baldwin wrote: J> > J> > Noted. I can't make a judgement if it is a smart restriction by C++ or not. J> > J> > In our case using enums as flags is common and handy and Werror=assign-enum in J> > J> > combination with __attribute__((flag_enum)) will make this use fortified J> > J> > against mistakes. J> > J> J> > J> Mostly my point is that over time we may be forced to convert away from enums to J> > J> plain constants if more of the base system starts using C++ anyway. At least for J> > J> enums exposed to userspace. J> > J> > But if C++ doesn't allow flag enums in principle, then they just can't go into J> > userspace headers, no matter how we compile the kernel. Basically we already J> > are there, and enabling Werror=assign-enum for kernel won't change anything, J> > will it? J> J> No, it won't change anything, but over time we might find we have to convert some J> enums to constants. I would only do those on an as-needed basis though, I wouldn't J> go about doing it now. I might suggest that we should avoid adding _new_ enums J> that are treated as flags.
I can't agree with that. If inpcb->inp_flags and tcpcb->t_flags were flag enums and we had Werror=assign-enum enabled, that would had saved me so much time in the last 10 years. I think we should use flag enums and use power of compiler to guard from human errors associated with using #define for flags. Of course the C++ restricts exposing that to certain KPIs. Those who really want to use C++ to mess with internal kernel structures, they always have <static_cast> -- Gleb Smirnoff
