Re: pruning stale C language variants

On Mon, Jun 22, 2026 at 01:59:28PM -0400, Greg Troxel wrote:
 > > 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.
 > 
 > I see these tokens as being in our namespace of languages, and I think
 > you are saying "we don't need to allow pkgsrc Makefiles to say c18
 > instead of c17".

Right.

 > >  > 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.
 > 
 > Agreed, but then it will mean something different, so it's good to purge
 > it now.

Indeed.

 > > 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.
 > 
 > If so that is a pre-existing problem in the code.

No... what I'm saying is that if you set the pkgsrc-level language to
c11, and are using an old compiler, we might need to transform that to
--std=c1x before running the compiler, and likewise for c23/c2x.

 > I think you're suggesting [...]

Yes, that instead.

-- 
David A. Holland
[email protected]