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
