Re: [bug-inetutils] Regarding IPv6 capabilities.

[Alfred M. Szmidt]

   >    I am now entering the Inetutils track with the intent of
   >    implementing IPv6 support where it is lacking. The first goal of
   >    mine is to deal with ftp and ftpd, then tftp and tftpd,
   >    respectively. So please inform me whether someone already is
   >    investing time here.
   > 
   > IPv6 support should already exist for the various daemons when used
   > with inetd--I'm for any patches that remove the whole socket setup for
   > all the daemons.  The clients _should_ support IPv6, but some are
   > lacking in that regard mostly due to not being able to read IPv6
   > addresses; e.g. the tftp client.

   This observation can only be conditionally true. The reason being
   that clients and server executables too offen rely on some code for
   verbose output that try to resolve addresses, thus introducing
   implicit family dependence. gethostbyname(3) is the worst culprit
   of them all! That inetd(8) is able to pass the socket, independently
   of address family, is only the frontside of the coin, so all clients
   and all servers should be reviewed again once a decision to support
   the dual stack has been made. I am volonteering here! Patience, please!

I wasn't suggesting that things shouldn't be reviewed, was just
stating as things "should" look like, wether that is then true or not
is a different story. :-)

   I have now arrived at a functional tftp client with the
   ability to use IPv4 ans IPv6, as well as withstanding
   RES_OPTIONS=inet6.

Lovley!

     in_port_t get_port (const struct sockaddr *);
     void set_port (struct sockaddr *, const in_port_t);

   Two questions arise:

     1) Are the names 'get_port', 'set_port' acceptable?

What do the two functions do exactly?

     2) Into which file in "inetutils/libinetutils/"
        are these best written?

I would create a new file, maybe called ports.c or ipvx.c or something
like that depending on what they do, what they try to abstract, etc.

   Both functions are simple switch statements to accomplish
   distinct processing of AF_INET and AF_INET6. They could
   even be written as inline code, but are best kept as
   separate code in order to enhance readability.

Sounds like a good plan.

Cheerio, happy hacking, and good night...