bug-inetutils
[Top][All Lists]
Advanced

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

Re: libtelnet: Make encryption decls compatible with C23.


From: Simon Josefsson
Subject: Re: libtelnet: Make encryption decls compatible with C23.
Date: Sun, 12 May 2024 09:20:17 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

Collin Funk <collin.funk1@gmail.com> writes:

> On 5/10/24 6:52 AM, Simon Josefsson wrote:>> $ ./configure
> CC="gcc-14.1" CFLAGS="-std=c23 -Wstrict-prototypes"
> --enable-authentication --enable-encryption --with-krb5
>> 
>> Ah, you answered my request from the earlier email already :-)
>
> :)
>
>> Looks good, and yes let's improve the compiler warning usage to catch
>> this.  I added a new idiom in last libidn2 that make sense to backport,
>> then --enable-gcc-warnings=error should result in build failures (we
>> should make sure it enabled -Wstrict-prototypes).  A C23 build would be
>> nice too, we alreayd build using latest gcc but not in C23 mode --
>> adding that would be simple.
>
> I think that one should get enabled by Gnulib, but I am not very
> skilled at m4/autoconf. So I may be wrong...
>
> I'll fix the telnet ones in a bit.

I enabled c23 build for gcc-14.1 now, and it passes:

https://gitlab.com/gsasl/inetutils/-/jobs/6830704753

I see we weren't using the warnings module from gnulib at all.  I recall
we were worried that if we are going to start fixing compiler warnings
we'll make the code even more different than other BSD-derived
implementations.  On the other hand, I don't see why fixing valid
compiler warnings is a bad thing.  This project have been conservative
about adapting to modern stuff.  I wish we could test it on some ancient
systems in a sustainable manner.

> There are still some old K&R declarations and declarations missing
> prototypes for Kerberos 4 stuff. I'm leaving them unchanged since I
> have no way of testing them.

Yeah, I think people have been trying to kill off Kerberos 4 and have
mostly succeeded.  However I think for InetUtils there is some value in
having a forever-maintained telnet etc with Kerberos 4 support.  All
these tools are basically mostly insecure anyway, so the protocol
security argument isn't applicable here.  Testability is a real concern
though -- we can't maintain code we can't test.  I wonder what the last
environment Kerberos 4 was working in was -- or if we reanimate it in
modern environments...  a bit further down on the priority list though.

/Simon

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]