Re: Is TODO up-to-date?

[Simon Josefsson]

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

> Hi,
>
> Is the TODO file generally up-to-date? Now that I have my copyright
> assignment done, maybe I can find some stuff to hack on.

Yay!

> Specifically, are these items still true?

I think you should pretty much assume very little is up to date or
correct in inetutils.

>> 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.

>>  - more system header files replacements
>>  - ruserok/wtmp stuff
>>
>> Mingw/cygwin support?

No idea.

> I think it would be nice to use more gnulib stuff. Less dealing with
> preprocessor conditionals and the sort. I know gnulib has some
> <sys/socket.h> stuff and inet_ntop/inet_ptoa but I haven't looked into
> that area much.

Yes this would be good.

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.

> 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.

> 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...

/Simon

signature.asc
Description: PGP signature