> 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf