Re: kern/48166: struct in_pktinfo incompatible with all other systems

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

The following reply was made to PR kern/48166; it has been noted by GNATS.

From: John Nemeth <jnemeth%cue.bc.ca@localhost>
To: christos%zoulas.com@localhost (Christos Zoulas), 
gnats-bugs%NetBSD.org@localhost,
        kern-bug-people%NetBSD.org@localhost, gnats-admin%NetBSD.org@localhost,
        netbsd-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/48166: struct in_pktinfo incompatible with all other systems
Date: Sat, 12 Oct 2013 23:45:30 -0700

 On Aug 31,  5:28am, Christos Zoulas wrote:
 } On Aug 31,  9:10am, jnemeth%CornerstoneService.ca@localhost 
(jnemeth%CornerstoneService.ca@localhost) wrote:
 } 
 } | struct in_pktinfo {
 } |    struct          in_addr ipi_addr;       /* src/dst address */
 } |    unsigned        int     ipi_ifindex;    /* interface index */
 } | };
 } | 
 } | On all other systems that I've checked (Illumos, Linux, and MacOSX) {none
 } | of the other BSDs have it} the struct is defined like:
 } | 
 } | typedef struct in_pktinfo {
 } |    unsigned        int     ipi_ifindex;    /* send/recv interface index */
 } |    struct          in_addr ipi_spec_dst;   /* matched source address */
 } |    struct          in_addr ipi_addr;       /* src/dst address in IP hdr */
 } | } in_pktinfo_t;
 } | 
 } 
 } And some don't have it:
 } 
 } Windows:
 } 
http://msdn.microsoft.com/en-us/library/windows/desktop/ms738572(v=vs.85).aspx
 
     Windows is weird and porting software to Windows is a major task.
 
 } AIX:
 } 
https://publib.boulder.ibm.com/infocenter/ieduasst/stgv1r0/topic/com.ibm.iea.zos/zos/1.13/Application-Middleware-Workload_Enablement/zOS_V1R13_zOS_UNIX_IPV4-pktinfo-Support.pdf?dmuid=20110825162439438278
 
      AIX is really weird, but okay.
 
 } Cygwin:
 } http://cygwin.com/ml/cygwin/2009-09/msg00150.html
 
      Cygwin says they do it the way they do because it's what the
 underlying Windows implementation does.  So, I'm going to write
 this one off as being not an independent implementation.  That
 leaves us with only two.
 
 } We could provide it, but it does not seem necessary or symmetric to the
 } IPV6 interface:
 } 
 } /*                   
 }  * IPV6_PKTINFO: Packet information(RFC2292 sec 5)
 }  */
 } struct in6_pktinfo {            
 }         struct in6_addr ipi6_addr;      /* src/dst IPv6 address */
 }         unsigned int    ipi6_ifindex;   /* send/recv interface index */
 } };
 
      I'm aware of this, and although it would be nice to be
 symmetrical, I don't think this should be an overriding concern.
 
      A couple more apps with problems were found after this PR was
 filed.  I also noticed a related PR (48280) was filed by you.
 
      Anyways, the most used Unix systems (and derivative) have
 ipi_spec_dst.  In order to maintain compatibility, we should have
 it as well.  If it really serves no purpose, then just create a
 dummy field and everybody will be happy.  But, given the other PR,
 I suspect it does serve a purpose.
 
 }-- End of excerpt from Christos Zoulas