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.)
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf