Re: CVS commit: pkgsrc/security/mit-krb5

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

Tobias Nygren <tnn%NetBSD.org@localhost> writes:

> On Tue, 29 Apr 2025 19:29:44 -0400
> Greg Troxel <gdt%lexort.com@localhost> wrote:
>
>> If I change to gnu99, then do things seem ok?
>
> Yes, go for it.

Thanks; committed.

> I'll note the use case we're discussing is different from how we
> traditionally have used the -std= option. Normally we use it to require
> a newer standard which sometimes implies depending a newer compiler
> package. Requiring a older standard is different and, as demonstrated with
> strdup(3), care must be taken when choosing the value.

Note that in pkgsrc today, we have separated requiring a compiler that
is capable of compiling a particular language family member (LFM), via
USE_CC_FEATURES and USE_CXX_FEATURES, and asking the wrappers to add
--std, via FORCE_C_STD and FORCE_CXX_STD.  Certainly USE_*_FEATURES has
been about higher LFMs.  I'm unclear on how many of the uses of
FORCE_*_STD are for higher LFMs than default vs lower.

My view is that pkgsrc having to set --std is working around upstream
bugs.  A program is (or should be, another bug) written to a specific
LFM, and the program's configure should probe for and set --std for that
LFM.  We are here because many do not, more or less.

Strictly, a package that uses POSIX should define some POSIX visibility
define, but that hides everything else, and the right set of defines is
non-portable and that gets silly fast.  My view is that some fairly
recent POSIX (but not necessarily the very latest) should be available
by default, and that it's seriously buggy of Linux to hide strdup(3),
required since 2001.  I really don't understand what the rationale is.
So code that uses that needs to have some define to work around that
Linux bug.

I find it odd and not really ok that gnu99 turns on strdup.  That's a
standard library procedure, not a language feature.

I also find it odd and not really ok that gcc15 is defaulting to C23 (or
probably gnu23).  Any program that needs C23 needs to check --std=c23
and add it, to built with other than gcc15, and such aggressive
defaulting only serves to encourage people that don't pay attention and
code to the environment in front of them.  But we of course can't fix
that.

I agree that if upstream can be fixed/patched so that it builds with
higher C LFMs, that's for the best.