tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



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

> On Tue, 29 Apr 2025 09:51:32 -0400
> Greg Troxel <gdt%lexort.com@localhost> wrote:
>
>> It turns out that the c11 is just an autoconf default and this is just
>> c99.  I'll wait until Thursday as this seems like a bigger change.
>
> On modern Linux it will fail due to missing strdup(3) if you set strict
> C99 mode. It needs to be either gnu99 or c99 with -D_GNU_SOURCE.
> Both tested on Fedora 42.

Is gnu99 c99 plus some extensions plus defining _GNU_SOURCE?  It seems
bizarre for a language std to set visibility defines.

It is odd that Linux doesn't have strdup by default, given:

     The strdup() function conforms to IEEE Std 1003.1-2001 (“POSIX.1”).

If I change to gnu99, then do things seem ok?

> This change should be fine here. In general though I am worried that
> venturing too far outside of the domain of "it builds with the default
> compiler settings" can cause unneccesary grief down the road.

I see it as moving grief around, and setting --std fixes the compilation
while leaving the possibility that using the headers with later std
might fail.

> Especially for packages that provide headers that other packages in
> turn may consume. Which is also why I prefer to patch away language
> features considered deprecated if it is either a small patch or the
> upstream is no longer very active.

The last release is less than a year ago, so I guess filing upstream
bugs is the right approach.


Maybe we should have a mode to randomly choose a --std in wrappers when
none is specified and find those bugs.  We've only gotten rid of the
cases where some compiler has a default that causes trouble and there
are many latent bugs.  Not nearly enough round tuits for that!


Home | Main Index | Thread Index | Old Index