bug-inetutils
[Top][All Lists]
Advanced

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

Re: [bug-inetutils] [PATCH] Implement IPv6 capability for the TFTP serve


From: Mats Erik Andersson
Subject: Re: [bug-inetutils] [PATCH] Implement IPv6 capability for the TFTP server.
Date: Fri, 24 Sep 2010 13:00:22 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

söndag den 19 september 2010 klockan 06:02 skrev Alfred M. Szmidt detta:
>    +  * libinetutils/tftpsubs.c (synchnet): Upgrade the variable "from"
>    +  to be "struct sockaddr_storage".
> 
> Linguistically, you changed the type of FROM to `struct
> sockaddr_storage'; local variables should be in capital letters.  Thus
> this should be something like:
> 
> (synchnet): Changed type of FROM to `struct sockaddr_storage'.

I have reread the GNU standards document, but I could not locate any
explanations on the means available to differentiate between various
kinds of variables: global, local, statically scoped and so on.
Please quote me a reference so that I can learn this aspect properly,
and use it for all future contributions.

A new effort at the changelog has been attempted, but I will not
comment further on that. Any further comments are welcome, though.

> switch (from.ss_family)
>   {
>   case AF_INET: family = "IPv4"; break;
>   case AF_INET6: family = "IPv6"; break;
>   default: family = "?"; break;
>   }

Check! Slight variation incorprated.

>    +  static char host[NI_MAXHOST];
> 
> Does the Hurd have NI_MAXHOST? I don't know.

Made into a conditional clause just to be safe.

A new version of the patching is attached to this email.


Let me for free provide a strong reason to reject also the new patch,
a patch with which I myself am content:

   There is no trace of conditioning the changes on either of

       IPV6
       HAVE_IPV6
       HAVE_DECL_GETADDRINFO
       HAVE_DECL_FREEGETADDRINFO
       HAVE_DECL_GAI_STRERROR
       HAVE_DECL_GETNAMEINFO
       HAVE_STRUCT_SOCKADDR_STORAGE
       
   so my suggestion fails to compile on any machine where IPv6
   is not supported!

The particular files, "libinetutils/tftpsubs.c" and "src/tftpd.c", are
manageable in size to rework to recover from this calamity, but the other
contribution of mine on "src/tftp.c" is already so much more involved
that it is clearly less stimulating to rework the patching. Not to
mention "ftp/*" and "ftpd/*", my next goals. Making them fit for
systems with IPv6, and those with only IPv4, that is some serious major
work. Believe me, I have already patched linux-ftpd/netkit-ftpd and
netkit-ftp for Debian GNU/Linux, where I was allowed to assume the
presence of IPv6 support.

Could I get to hear some wise words on principles here? May IPv6 code
be implemented and committed first, and then afterwards be refined to
reimplement the fixes to take care of IPv4-only systems, or must both
settings be coped with in one single go? The answer will seriously
affect the labour and the pace with which the needed changes can be
implemented.


Regards,
Mats E A

Attachment: 0001-Implement-IPv6-capability-for-the-TFTP-server-2.patch
Description: Text Data

Attachment: signature.asc
Description: Digital signature


reply via email to

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