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.
Header pollution definitely makes it easier to write nonportable
applications.
do you have any
information about when the clause was introduced? was it with
the use of sockaddr_storage?
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf