Re: enabling -Werror=assign-enum for kernel

Kyle Evans <[email protected]>
Newsgroups gmane.os.freebsd.current
Message-ID <f88131eb-ec6f-445c-8c64-6f0af8bbd17a__38226.9253068202$1787767459$gmane$org@FreeBSD.org>
On 8/26/26 12:23, Gleb Smirnoff wrote:
>    John,
> 
> On Wed, Aug 26, 2026 at 01:15:27PM -0400, John Baldwin wrote:
> J> > J> Note that C++ doesn't allow this at the language level.  When I converted ctld to
> J> > J> C++ I had to adjust some enums to be simple #define's instead in the ctl headers.
> J> >
> J> > Noted.  I can't make a judgement if it is a smart restriction by C++ or not.
> J> > In our case using enums as flags is common and handy and Werror=assign-enum in
> J> > combination with __attribute__((flag_enum)) will make this use fortified
> J> > against mistakes.
> J>
> J> Mostly my point is that over time we may be forced to convert away from enums to
> J> plain constants if more of the base system starts using C++ anyway.  At least for
> J> enums exposed to userspace.
> 
> But if C++ doesn't allow flag enums in principle, then they just can't go into
> userspace headers, no matter how we compile the kernel.  Basically we already
> are there, and enabling Werror=assign-enum for kernel won't change anything,
> will it?
> 
I don't really have comments on the rest of this, but at least one of our downstreams does
use C++ in the kernel and it'd be nice if we didn't have anything too critical require too
heavy of patching to work in that environment.

Thanks,

Kyle Evans
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.