Subject: (IPng 7206) Re: sockaddr_storage nit

From: Mukesh Kacker <[email-masked]>
Date: Thu, 18 Feb 1999 22:41:25 -0800 (PST)

> 
>   My original statement was correct as made. The entire point of having those
> fields -- which are there primarily because I kept pushing for them -- was to
> be able to access the sa_len and sa_family equivalents without the need for
> a cast, just like you can with any other struct sockaddr_foo.
> 

That might have been your motivation for proposing sockaddr_union. But
when you combine various sockaddr_foo, you bring together the issues
of extensibility, binary compatibility, alignment, and maximal size
and sockaddr_storage tries to solve all that avoiding some of the
potential pitfalls of unions.

I don't have any problem with having ss_family (and ss_len where applicable)
though. If not, that was a workaround to the situation. It is
not unheard of to have nits and bugs in specs....and I am not sure
what the process is to fix such things in IETF in such an advanced stage.

> 
>   Would this really take away the global ss_ namespace? That's icky.
> 

Yes, that is my understanding. Perhaps I don't understand/remember all
the reasons there but I do feel it is overkill.
One of the the reasons there are that people use field names
in #defines to abbreviate when there are strucutures within structures or
for other reasons (e.g. the s6_addr define in the draft).
I would rather reserve it in those exceptional cases and limit the prefix
reservation to within that structure. But there may be more to it.
If not, it is an optimzation for far out scenarios while burdening the
common case. With this current practice, formal standards make it extremely
hard to write any code that strictly follows all the rules of the
formal standards :-) 

- Mukesh Kacker
  Internet Engineering
  Solaris Software
  Sun Microsystems Inc
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------