[Top][All Lists]

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

Re: [bug-inetutils] Restoration of ping.

From: Alfred M. Szmidt
Subject: Re: [bug-inetutils] Restoration of ping.
Date: Wed, 02 May 2012 14:47:37 -0400

   >       Just tell me why on earth `libicmp/icmp.h' was ever written
   >       in the form it exists today. It differs from
   >       <netinet/ip_icmp.h> in more than forty macros
   >       alone. Backwards is really the nicest thing I can express
   >       about that construct. I have just begun the process of
   >       adapting our source files to fit the official header file
   >       <netinet/ip_icmp.h>, thus abondoning `libicmp/icmp.h'.
   >    ip_icmp.h isn't a standardised header though.  I'm not sure
   >    about rewriting ping/etc to use this over icmp.h;
   > (which means; lemme think about it for a few days, and feel free
   > to add arguments for the change in the mean time)

   How can you tell that <netinet/ip.h> be standardised, while
   <netinet/ip_icmp.h> no be so?

Neither of them are standardised; i.e. they are not in POSIX, or
required by any RFCs that I know of.  This shouldn't be a reason to
reject using netinet/ip_{icmp,}.h, but if there was a standard for
them then that would definitly be something (and many times I have
pondered about starting a "Portable Network Specification-ix" since
the lack of standardisation irks me--typical irky moment is the -c
option in ping or the default behaviour of ping).

   Can you name me a libc implementation where <netinet/ip_icmp.h> is
   broken from your viewpoint?

To be picky: no (standard) C library implements that header.  :-) It
is always an extention.

   Well, OpenSolaris, NetBSD, OpenBSD, FreeBSD, and DragonFly BSD are
   in agreement of using "struct icmp" and all macro names, save that
   the BSDs might add a few beyond ICMP_MAXTYPE. Some small
   disagreement on n_short/uint16_t and n_time/uint32_t exists,

   Then comes Glibc along, keeps all of the above, adds a complete and
   disjoint set of macros, and duplicates the old structure as 'struct
   icmphdr'. Chicken race, if I ever saw one!

I not convinced by such an argument (foo vs. bar); the simple case is
that GNU is our main target, and the GNU C library is the C library of
that system.  This is not to say that we should make it hard for to
get stuff running on other systems, or make our life hard by having to
maintain a lot of wraper code.  The work you have done in making
things more portable, more robust in this regard is amazing.

But an argument that BSDs do that, and GNU does this is not convincing
to me.

   One major problem is that the help text and info text for "ping" is
   naming the ICMP message types according to Glibc, and this is not
   what the literature or RFSs consider correct, thus impeding usage.

We should name it after glibc, since that is the main C library on
GNU.  The problem with the RFCs is that they are non-free
documentation; so we should not really refer to them even though they
are the standard.  Same with POSIX.

   For reference I append the changes needed for 'libicmp/icmp.h'.

Could you post a diff?

reply via email to

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