> On 26. Aug 2026, at 20:59, Gleb Smirnoff <[email protected]> wrote: > > 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. Hi Gleb,
could you elaborate on what took time? Knowing this would help me to understand the benefits of your proposal. Best regards Michael > > 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 >
