Subject: Re: RFC3678: header incompatibility

From: Bill Fenner <[email-masked]>
Date: Tue, 16 Oct 2007 01:15:40 -0400

>	i'm aware of that line, but that does not really meet my observations.

You asked that we revise the RFC to be compatible with POSIX.
I observed that the RFC is not incompatible with POSIX.  Now you
are asserting that isn't what you were really asking?

>	if the above POSIX line suggests inclusion of <sys/socket.h> from
>	<netinet/in.h>, why freebsd did not do that and defined sockaddr_storage
>	in two places?

Because FreeBSD chose a different implementation.

Are you suggesting that POSIX is wrong, or that we were wrong to write
the spec to be compatible with what POSIX requires?  Or are you saying
that we should have ignored POSIX and instead written the spec to
what FreeBSD, OpenSolaris and *BSD prefer?

(I'd note that MacOS X has a simple #include <sys/socket.h> in
<netinet/in.h>, so apparently it's not impossible to implement
things that way.)

  Bill

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Tue, 16 Oct 2007 19:55:02 +0900 (JST)

> <netinet/in.h>, so apparently it's not impossible to implement

	i see.  i was not doing enough homework.  sorry about that.

	(yup, this is not a forum to talk about posix, but...)
	the older version of POSIX specification did not have "may include
	<sys/socket.h>".
	http://www.opengroup.org/onlinepubs/007908799/xns/netinetin.h.html

	i am under impression that "may include <sys/socket.h>" clause can
	lead to portability issues in applications - some application writers
	will include <netinet/in.h> only and it will compile fine on some
	platforms, and not on some other platforms.  do you have any
	information about when the clause was introduced?  was it with
	the use of sockaddr_storage?

itojun

---

From: Bill Fenner <[email-masked]>
Date: Tue, 16 Oct 2007 09:59:07 -0400

>	platforms, and not on some other platforms.

Header pollution definitely makes it easier to write nonportable
applications.

>	do you have any

I'd guess so, but I don't know for sure.  You can see that the SUSv2
that you pointed to didn't have sockaddr_storage.

Starting with a different angle: if there had been a different way
to design the API, I think we would have.  The use of sockaddr_storage
in these structs is incredibly wasteful, since it's usually way bigger
than a sockaddr_in6, which is the biggest thing that it has to convey.
However, we were aware of no other socket option calls that required
copying additional user memory to kernel memory (e.g., because we
passed a pointer in the middle of the struct) and didn't want to
introduce that requirement for fear of being difficult to implement
on some platforms.

The best option might have been to introduce a real new API, not
just socket options; obviously then we could use similar options to
bind()/connect() et al. and just accept a sockaddr * as one of the
arguments.  But this is a somewhat higher implementation overhead -
updating libc, syscall tables, etc - and IPv4 multicast didn't do
this - so again it was a matter of trying to reduce barriers to
imnplementation.

  Bill