>As RFC 2553 suggests, sockaddr_in usage should be replaced by
>sockaddr_storage to make code more protocol independent. This means
>an interface change. This can't be avoided in case of the SVCXPRT
>change. Basically there are 2 options:
>
>	a) Go for struct sockaddr_storage completely, including in the
>	   interface. Use versioning for the old interface for backward
>	   compatibility.
>	b) Only use struct sockaddr_storage inside SVCXPRT (and use
>	   versioning there too), but do not change the sockaddr_in *
>	   paramemeters. Rely on the application to check for address
>	   family and do the right thing.
>
>I prefer a), but it does mean that any source code using the RPC 
>library calls won't compile anymore, and needs to be modified.
>
>Solaris 8 seems to have kept the old interface. Disadvantage is
>that this may lead to source code compiling, but crashing because
>an address may resolve to an ipv6 address, not fitting in the
>sockaddr_in structure it passed a pointer to. I'd rather have
>the failure at compile time.
>
>Opinions?

	I believe compatibility with other source is the most important thing,
	so if I were you I would make plans on route (a) and talk with Solaris
	guys (where is the standardization body for RPC API?).

	using "struct sockaddr_storage *" does not seem right to me.  using
	"struct sockaddr *" and separate "int len" is the way to go.
	("int len" is needed for Solaris and Linux, where sa_len is not given)

itojun