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