Re: heads up RE autoconf C23 vs legacy code

[Greg Troxel <gdt%lexort.com@localhost>]

Edgar Fuß <ef%math.uni-bonn.de@localhost> writes:

>> a program should document what dialect it is written in
> I think you can't blame people having written a C program close to half 
> a century ago for not having forseen that people would be changing the 
> language in incompatible ways.

I'm not blaming them.  Just saying that as soon as there was a new C std
that rejected programs that were valid under a previous std, it becomes
a bug not to document what langauge the program is in.

>> and probe for a[nd] set --std for it.
> Unfortunately, there's no #pragma language-level. In Perl, I simply write
> 	use 5.42;
> (and use feature 'foobar';)
> in the source to document which Perl exactly I write in.

Yes, but most invocations of a C compiler in practice support --std=cnn,
and build systems should try that and add it if it works.

>> Another option would be to have the wrappers error out on --std=c23, if
>> c23 is not in USE_CC_FEATURES.  That should fix all of those
>> look-for-c23 enable it bugs in autoconf, in programs that are written in
>> some earlier dialect.   That actually could be a good fix.

> That sounds like an *excellent* idea to me. Generally error out on --std=cnn 
> if pkgsrc's logic chose a different language level, at least for 
> PKG_DEVELOPER=YES? This may create an enormous amount of fall-out initially, 
> but then all these hard-to-find build failures would be gone.

I don't see this as being about PKG_DEVELOPER.  If the package doesn't
declare that it needs a particular C std, then trying to use it is a
bug.   For example, taking c++ out of USE_LANGUAGES and using c++ fails,
always.  This is really the same thing.

I suspect this will mostly catch the autoconf bug, but that's me
guessing.