Re: pruning stale C language variants

[David Holland <dholland-pkgtech%netbsd.org@localhost>]

On Sun, Jun 14, 2026 at 02:45:05PM -0400, Greg Troxel wrote:
 > I don't want to do this in freeze, but in mk/compiler/gcc-style-args.mk,
 > we have
 > 
 >   _GCC_C_DIALECTS=        c89 c90 c99 c9x c11 c1x c17 c18 c2x
 > 
 > I see c9x and cx1x as redundant.  I have no idea what c18 is for.  None
 > of these 3 otherwise appear under mk/.  So I'd like to adjust to
 > 
 >   _GCC_C_DIALECTS=        c89 c90 c99 c11 c17 c2x
 > 
 > which is a no-op because these, if in USE_CC_FEATURES, will do nothing
 > now.  And similarly for the gnu variants, also not appearing otherwise.

According to the gcc14 man page, --std=c18 is a synonym for --std=c17,
seemingly because even though everyone calls it the 2017 version it
actually appeared in 2018. I don't see any reason we need to handle
that.

The same man page also describes c9x and c1x as deprecated.

 > I propose to make this change post freeze.

Seems reasonable.

 > Also c2x should now be c23, I would think.  That requires adjusting all
 > such USE_CC_FEATURES and FORCE_C_STD lines as part of renaming.   I
 > propose to do this after freeze, if it seems not massive.

Yes, it should be c23. I assume the same forces that brought us the
fiasco called c23 are still at work, though, and at some point we'll
need c2x back, or c3x, for the next round. But that can wait.

There is one fly in this ointment, which is that we might need to feed
c2x, c1x, or even c9x to older compilers. I'd expect that any needed
support for this and c1x/c9x would already be in place; it might be
necessary to extend that to provide c2x in place of c23 for some
versions.

-- 
David A. Holland
dholland%netbsd.org@localhost