Re: default C versions

[Havard Eidnes <he%NetBSD.org@localhost>]

> My understanding is hazy, but since I haven't seen anything on the list,
> I think:
>
>   Lots of packages probably need a C99 compiler, but aren't tagged as
>   such -- because pretty much every system has a C99 compiler and
>   compiles in C99 by default, because in 2023, C99 is beyond normal.
>
>   I am guessing EL7 uses a compiler that uses C90 (== C89) by default.
>
>   It seems obviously buggy in the larger ecosystem that different
>   compilers have different defaults in terms of which language they are
>   compiling for (unapologetically taking the view that C is a language
>   family and C99 is a language).
>
> and thus I wonder if the wrappers should be passing --std=c90 when there
> is no c99 or higher in USE_LANGUAGES.  That would in theory cause
> packages that need c99 to fail even when c99 is default, which would get
> the mis-tagging of USE_LANGUAGES fixed earlier.
>
> An alternative would be to declare that c99 is normal and c90 deficient
> and have the wrappers on systems with really old compilers add
> --std=c99, which is sort of like putting c99 in the default
> USE_LANGUAGES, but messier, and that doesn't seem great to do ad hoc.

Hmm, tangentially related, since I do pkgsrc bulk builds for
NetBSD/macppc 8.0, I find quite a bit of issues of this sort:

/usr/pkgsrc/textproc/syntax-highlighting/work/syntax-highlighting-5.98.0/src/indexer/katehighlightingindexer.cpp:179:42: error: 'as_const' is not a member of 'std'
             for (const auto &styleName : std::as_const(unusedNames)) {
                                          ^
"std::as_const" is according to

  https://en.cppreference.com/w/cpp/utility/as_const

a c++17 construct, and obviously the C++ compiler in 8.0 (5.5.0)
does at least not by default support c++17.

I'm wondering a bit about what to do in this case.

I could add a USE_LANGUAGES+=c++17 (or gnu++17 if the package uses
alloca()) to the package.  Arguably, that would ba a correct
declaration given the use of the above construct, but it's far from
certain that it will fix the build on this platform, as this does
nothing to influence which C++ compiler is used.

However, with C++ it's even more fraught with danger than with C to
mix use of different C++ compilers, since the ABI has evidently
changed over time, and sometimes in non-backward-compatible ways, if
I've understood correctly.

So, what to do?  Nothing or add a USE_LANGUAGES+= setting?

Regards,

- Håvard