Re: Is TODO up-to-date?

[Collin Funk]

Hi Simon,

On 5/2/24 10:55 AM, Simon Josefsson wrote:
>> Specifically, are these items still true?
> 
> I think you should pretty much assume very little is up to date or
> correct in inetutils.

Haha, good to know. :)

>>> generally use gnulib for portability more than we use today:
>>>  - getaddrinfo/getnameinfo with IDN support to simplify IDN
>>>  complexity
> 
> There were discussions around this earlier.  I wanted to move IDN usage
> to getaddrinfo/getnameinfo rather than explicit linkage to
> libidn/libidn2 but IIRC Mats-Erik objected that this would mean dropping
> IDN support on non-glibc platforms which is true.  My take is that
> gnulib's getaddrinfo/getnameinfo should be extended to use libidn2 and
> IDN functionality on non-glibc platforms, and then inetutils should use
> that, and we should drop the direct linkage to libidn2.

Ah, I see. The one in gnulib right now seems very much targeted
towards Windows from what I can tell.

> I worry about self-tests though, it would be nice to beef up on that.
> There is a pretty substantial GNU/Linux-centric self-test pipeline here
> (I just noticed the last commit broke this due to indentation changes):
> 
> https://gitlab.com/gsasl/inetutils/-/pipelines
> 
> Adding some BSD, Solaris or other hosts to this would be nice, it is
> hard to know what currently works before we break/improve things.

Good point. I don't know too much about the GitLab stuff so I can't
help there, sorry.

I do use FreeBSD sometimes so it would be nice to keep things working
there. Some basic build-checks on my own system is better than nothing
I suppose.

>> Also, I have attached two patches that modernize stuff to match
>> current gnulib. First, with the 'environ' module there is no need for
>> 'extern char **environ'. It is handled in unistd.h by gnulib [1].
> 
> Looks good, please push.  I don't think a NEWS entry is necessary for
> this.

I don't have commit access. My savannah account is here:

    https://savannah.gnu.org/users/collinfunk

if you want to add me to the Inetutils group.

>> Second, now that the 'stdbool' module emulates C23, there is no need
>> to include stdbool.h. If the compiler doesn't support bool stuff as a
>> keyword the header is included in config.h.
> 
> Interesting -- is it recommended by gnulib to remove '#include
> <stdbool.h>'?  That is a fairly common idiom for using bool types, so it
> seems a bit odd to actively remove it and relying purely on config.h.
> Does it harm anything?  In the odd scenario that someone ports this to a
> platform with stdbool.h but rips out config.h this will cause additional
> breakage.  Not sure if we care about that though, anyone going in that
> direction will have to own all pieces anyway...

Good point. No there shouldn't be any harm in leaving the include. In
the case of modern gnulib it would just be a no-op, since it is
handled in config.h. I can't imagine any platform that doesn't have
the header and where including it twice would break things.

The gnulib change was to match C23 which makes it a keyword supported
by the compiler. I suppose it was core codebases who use a more modern
style, see Coreutils for example. Since Inetutils still has it's
pre-C99 BSD history visible, perhaps it would look strange removing
it. :)

Collin